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ABSTRACT 


This  thesis  outlines  the  objectives,  structure,  and 
operation  of  the  software  designed  to  meet  requirements  set 
forth  by  Development  Test  Objective  700-6  for  the  space 
shuttle  Discovery  mission  STS- 51.  The  primary  goals  were  the 
comparison  of  state  vector  information  produced  by  GPS  sources 
and  Discovery's  inertial  navigation  corr5)uter,  and  the  real¬ 
time  display  of  relative  position  and  rendezvous  information 
between  Discovery  and  a  retrievable  shuttle  pallet  satellite. 
In-flight  and  post- flight  examination  of  GPS  and  inertial 
state  vectors  provided  the  first  step  in  the  development  of 
GPS  as  an  on-orbit  navigation  system.  Analysis  of  the  Orbiter 
and  target  satellite  state  vectors  produced  real-time 
graphical  displays  of  operationally  significant  data  to  the 
Discovery's  flight  crew  during  rendezvous  and  proximity 
operations . 
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I.  ZNTKODnCTIOM 


On  September  12,  1993,  space  shuttle  Discovery  mission 
STS' 51  successfully  launched  into  orbit  carrying  several 
pieces  of  hardware  and  software  in  support  of  Development  Test 
Objective  (DTO)  700-6.  The  purpose  of  DTO  700-6  was  to 
investigate  the  use  of  the  Global  Positioning  System  (GPS)  for 
shuttle  Orbiter  navigation  and  Orbiter/satellite  relative 
navigation. 

Components  of  the  experiment  included  (1)  the  shuttle 
Orbiter' s  navigation  computer  and  pulse  code  modulation  master 
unit  (PCMMU)  containing  Orbiter  navigation  data  and  telemetry, 
(2)  a  Trimble  Advanced  Navigation  Sensor  (TANS)  QUADREX  GPS 
receiver  for  gathering  GPS  state  vector  information,  (3)  a  GRID 
1535  Portable  GRID  Systems  Con^uter  (PGSC)  with  software  for 
stripping  and  sending  desired  data  packets  from  the  Orbiter' s 
128  Kbyte  data  stream  used  by  the  PCMMU  to  (4)  a  second  GRID 
1530  PGSC  with  Naval  Postgraduate  School  (NPS)  and  TANS  GPS 
software  packages  for  analyzing  and  storing  the  data,  and  (5) 
the  German  ORFEUS/SPAS  satellite  with  an  onboard  GPS  receiver. 

A.  STS-51  DTO  700-6  MISSION  OVBRVISN 

The  STS-51  mission  was  the  first  space  shuttle  flight  to 
successfully  carry  and  operate  a  TANS  GPS  receiver  in  space. 
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This  provided  the  unique  science  opportunity  of  collecting  GPS 
state  vector  data  and  comparing  this  data  with  Orbiter  state 
vector  data  generated  by  ground  tracking  and  propagated  by  the 
Orbiters  navigation  computer  to  determine  the  reliability  of 
GPS  as  an  on-orbit  navigation  aid.  Additionally,  the  space 
shuttle  Discovery  deployed  and  retrieved  a  shuttle  pallet 
satellite  (SPAS)  also  carrying  a  GPS  receiver.  This  presented 
the  opportunity  to  compare  ground  tracking  state  vectors  with 
SPAS  GPS  state  vectors  as  well  as  evaluating  TANS  GPS  and  SPAS 
GPS  relative  navigation  during  rendezvous  and  proximity 
operations. 

The  TANS  QUADREX  GPS  state  vector  data  was  compared  with 
the  Orbiter  inertial  navigation  system  (INS)  state  vectors 
propagated  by  the  Orbiter' s  navigation  computer.  A  comparison 
of  the  states  would  demonstrate  the  feasibility  of  using  GPS 
data  to  update  the  Orbiter  navigation  system.  The  Orbiter  INS 
state  vector  is  presently  updated  by  data  uplink  from  earth 
based  tracking  stations  approximately  every  five  to  eight 
hours  to  correct  for  inertial  system  drift.  Given  reliable  GPS 
state  vector  information,  it  was  expected  that  by  comparing 
the  Orbiter  INS  state  vector  with  the  TANS  GPS  state  vector, 
the  Orbiter  inertial  position  vector  drift  away  from  the 
Orbiter  TANS  GPS  position  vector  over  time  would  be  observed. 
On  an  INS  update,  it  was  predicted  that  the  inertial  position 
would  return  to  some  position  close  to  the  TANS  GPS  position 
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vector,  lending  some  credibility  to  the  concept  of  using  GPS 
for  navigational  updates. 

The  STS- 51  mission  profile  called  for  releasing  the 
ORFEUS/SPAS  satellite  on  flight  day  two,  maneuvering  the 
Orbiter  away  from  the  satellite  for  several  days  to  allow  data 
collection,  then  a  rendezvous  to  capture  SPAS  on  flight  day 
nine  prior  to  de-orbiting.  ORFEUS/SPAS  state  vector 
information  was  availcUale  via  data  link  of  it's  onboard  GPS 
receiver  data,  and  by  ground  tracking  and  uplink  of  a  target 
state  vector.  Orbiter  and  JPAS  state  vectors  were  then 
available  on  the  128  Kbyte  data  stream  sent  from  the  PCMMU  to 
the  GRID  1535.  The  NPS  software  tools  contained  in  the  PGSC 
received  data  packets  from  the  GRID  1535  and  the  TANS  GPS  unit 
to  provide  real-time  INS/GPS  difference  plots,  several  real¬ 
time  relative  motion  displays,  and  relative  position 
prediction  displays  that  normally  would  require  ground 
tracking  information  and  manual  plotting.  These  tools  lay  the 
foundation  for  the  use  of  GPS  as  an  aid  to  on  orbit  navigation 
and  spacecraft  rendezvous  and  docking.  Lessons  learned  will  be 
useful  for  future  shuttle  missions  and  essential  to  the 
development  and  operation  of  a  manned  space  station. 

B.  PURPOSE  OF  DEVELOPMENT  TEST  OBJECTIVE  700-6 

The  DTO  700-6  Objectives  were  defined  by  the  DTO  software 
plan  piiblished  by  the  STS -51  DTO  700-6  manager.  The  DTO 
software  was  divided  into  four  levels  in  order  of  priority. 
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The  Level  I  DTO  objectives  as  stated  in  the  software  plan 
were  to  operate  the  TANS  GPS  receiver,  display  data  on  the 
PGSC  CRT,  and  store  state  vectors  and  other  GPS  data  packets 
in  files  for  post  flight  analysis  (PFA) . 

The  Level  II  DTO  code  was  to  visually  display  the  relative 
difference  of  the  Orbiter  INS  state  vector  and  the  Orbiter 
TANS  GPS  state  vector  in  real  time.  If  possible.  Level  II  code 
was  also  to  perform  a  similar  comparison  between  the  target 
vector  for  SPAS  and  the  SPAS  GPS.  State  vector  inputs  to  the 
progrcun  were  to  be  manually  or  automatically  input.  Level  II 
DTO  code  is  contained  in  the  NPS  software. 

The  Level  III/IV  DTO  code  objectives  included  using  state 
vector  information  supplied  by  the  Orbiter,  GPS  and  ground 
tracking  to  provide  real-time  relative  motion  plotting  of  the 
ORPEUS/SPAS  satellite  and  the  Orbiter.  Level  III/IV  DTO  code 
is  also  contained  in  the  NPS  software. 

C.  NPS  SOFTNASE  OBJECTIVES 

The  NPS  software  package  written  for  STS- 51  was  designed 
to  meet  the  requirements  set  forth  in  the  DTO  700-6  software 
plan.  This  was  accomplished  through  the  use  of  state  vector 
difference  plots  (Level  II)  and  relative  position  plots  (Level 
III/IV)  .  In  addition,  the  NPS  software  was  designed  to  provide 
target  locating  data  in  the  form  of  pitch/yaw/distance 
information,  as  well  as  predicted  motion  plotting  to  aide  in 
rendezvous  and  proximity  operations.  These  tools,  while 
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inspired  by  the  GPS  DTO,  do  not  rely  on  GPS  to  provide 
navigation  solutions.  The  NPS  software  only  requires  target 
and  Orbiter  state  vectors.  Therefore,  any  state  vector  source 
(INS,  GPS,  ground  targeting,  approach  radar,  or  a  manual 
keyboard  entry)  may  be  used  to  provide  an  automated 
situational  awareness  tool  to  the  flight  crew. 

D.  SUMMARY 

The  scope  of  this  thesis  was  to  develop  the  Naval 
Postgraduate  School  State  Vector  Analysis  and  Relative  Motion 
Plotting  (NPS)  software  residing  in  the  GRID  1530  PGSC, 
integrate  that  software  with  existing  software  and  hardware  to 
accomplish  the  DTO  700-6  objectives,  support  the  STS-51 
mission  during  training  and  actual  flight,  and  perform  post- 
f light  analysis  of  the  collected  data. 

Testing  of  the  NPS  software  was  accon^lished  on  a  desktop 
computer  (PC)  with  software  emulation  of  the  flight  inputs. 
Testing  of  the  complete  integrated  flight  software  package 
(w/o  TANS  GPS  data)  and  related  DTO  components  was  performed 
in  the  space  shuttle  integrated  flight  simulator  at  Johnson 
Space  Center  prior  to  flight  aboard  STS-51. 

The  NPS  software  was  written  in  the  'C'  programming 
language  using  Borland  C++.  Several  proven  'off  the  shelf' 
software  tools  were  integrated  with  tools  developed  as  a  part 
of  this  project.  'Off  the  shelf'  tools  included  a  proven 
Cowell  orbit  propagator,  a  GPS  state  vector  filter,  and 
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consnuni  cat  ions  software.  Developed  software  included  interface 
routines,  data  processing  and  plotting  routines,  and 
rendezvous  aids. 

Details  of  the  NPS  software,  its  role  in  the  STS- 51 
mission  and  DTO  700-6,  code  development,  and  post  flight  data 
analysis  are  contained  within  this  thesis.  Chapter  II  contains 
a  description  of  DTO  700-6,  including  hardware  and  software 
components.  Chapter  III  contains  an  introduction  to  spacecraft 
relative  motion  and  plotting.  Chapter  IV  contains  an  overview 
of  the  STS- 51  mission  as  it  relates  to  DTO  700-6.  Chapter  V 
contains  a  detailed  desription  of  the  NPS  software  structure 
and  organization.  Chapter  VI  contains  a  detailed  description 
of  major  software  functions.  Chapter  VII  contains  a  desription 
of  the  NPS  program  flow  and  operation.  Chapter  VIII  discusses 
data  collection  and  analysis.  Chapter  IX  discusses  lessons 
learned.  Chapter  X  contains  results  and  conclusions.  A 
glossary  of  terms,  software  user's  manual,  and  the  source  code 
are  contained  as  appendices. 
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II.  DSVBLOFlflDIT  TBST  OBJBCTIVB  700-6  DESCRIPTION 


A.  DEVELOPMENT  TEST  OBJECTIVE  700-6  OBJECTIVES 

Generally  stated,  the  purpose  of  DTO  700-6  is  the 
investigation  of  the  use  of  GPS  as  a  source  for  on  orbit 
inertial  navigation  system  update  and  relative  -  ion 
determination  between  the  space  shuttle  and  a  jet 
satellite.  The  goals  of  DTO  700-6  are  described  in  detail  by 
the  objectives  of  each  of  the  four  levels  of  the  DTO  software 
plan. 

•  Level  I  -  Operate  the  TANS  QUADREX  GPS  receiver.  Display 
data  on  the  CRT  and  store  state  vectors  and  engineering 
data  in  files. 

•  Level  II  -  Input  the  Orbiter  state  vector  by  hand  or 
automatically  to  perform  TANS  GPS  vs  Orbiter  state  vector 
comparison.  If  availcQsle.  perform  Orbiter  target  vector  vs 
SPAS  GPS  state  vector  corrqparison. 

•  Level  III  -  Use  Orbiter  GPS  and  SPAS  GPS  state  vectors  in 
a  rendezvous  display  program  to  evaluate  relative  GPS 
solution  with  ground  and  onboard  solution. 

•  Level  IV  -  Integrate  the  Orbiter  GPS  and  inertial  state 
vectors,  the  SPAS  GPS  and  target  state  vectors,  and 
Orbiter  attitude  data  into  one  program  showing  the  entire 
rendezvous  and  proximity  operations  profile. 

Level  I  objectives  were  met  by  TANS  GPS  software  written 

by  Mike  Arnie  of  the  Lockheed  Engineering  and  Sciences 

Corporation  for  NASA.  The  TANS  GPS  software  runs  in  the  GRID 

1530  PGSC  and  accepts  input  from  the  TANS  GPS  unit  via  an  RS- 

422  ccQsle  and  port. 
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Level  II,  III,  and  IV  objectives  were  achieved  by  the  NPS 
software  running  co- resident  in  the  GRID  1530  PGSC.  The  NPS 
software  accepted  TANS  GPS  state  vector  information  frcan  the 
TANS  GPS  software  and  all  other  necessary  information  from  the 
Orbiter's  computer  via  the  GRID  1535  PGSC  and  an  RS-232  port. 

B.  DTO  700-6  CQMPONBNT  DESCRIPTIONS 
1 .  Hardware  Components 

a.  Pulse-Code  Modulation  Master  Unit  (PCMMO) 

The  PCMMU  was  the  source  for  the  128  Kbyte  data 
link  information.  This  data  stream  contains  up-link  and  down¬ 
link  telemetry  used  by  the  Orbiter  and  NASA  flight 
controllers.  Information  contained  in  the  telemetry  included 
Orbiter  and  SPAS  target  state  vectors,  Orbiter  attitude 
information  in  the  form  of  a  quaternion,  and  SPAS  telemetry 
including  SPAS  GPS  state  vectors. 

b.  GRID  1535  Portable  GRID  Systems  Caaputer  (PGSC) 
The  GRID  1535  laptop  corrqouter  was  the  interface 

between  the  PCMMU  and  the  GRID  1530  PGSC.  It  was  linked  to  the 
PCMMU  through  a  128  Kbyte  data  link  cable.  The  GRID  1535 
contained  the  PC  Decoramutator  (PCDecom)  software  package. 
PCDecom  transmitted  data  packets  from  the  GRID  1535  PGSC  to 
the  GRID  1530  PGSC  via  the  RS-232  communications  port  for  use 
by  the  NPS  software. 
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c.  GRID  1530  Portable  GRID  Syatema  Coaputer  (PGSC) 

The  GRID  1530  PGSC  is  a  portcUale  ccn^uter  with  a  10 

MHz  80386  microprocessor.  8  Mbytes  RAM.  and  40  Mbyte  internal 
hard  drive.  The  GRID  1530  PGSC  contained  the  NPS  software  and 
the  TANS  GPS  software.  It  received  state  vector  data  from  the 
GRID  1535  via  the  RS-232  port  and  from  the  TANS  QUADREX  GPS 
receiver  via  the  RS-422  port. 

d.  TANS  Quadrex  GPS  Receiver 

The  Trimble  Advanced  Navigation  Sensor  (TANS)  is  a 
six  channel  GPS  receiver  which  provides  position,  velocity, 
time  and  other  information  to  external  data  terminals.  The 
TANS  GPS  receiver  was  connected  to  the  GRID  1530  PGSC  via  the 
RS-422  port.  Communications  and  control  of  the  TANS  unit  was 
handled  by  the  TANS  GPS  software  in  the  GRID  1530  PGSC.  The 
TANS  GPS  receiver  has  three  antennae  that  were  velcro  mounted 
in  the  Orbiter  windows  on  Flight  Day  one  of  the  mission.  This 
antenna  arrangement  made  TANS  GPS  reception  a  function  of  the 
Orbiter' s  attitude.  For  further  information  on  the  TANS  GPS 
receiver,  see  [Ref.  1] . 

e.  ORFEOS/SPAS 

The  Orbiting  Retrievable  Far  and  Extreme 
Ultraviolet  Spectrometer  (ORFEUS)  housed  onboard  the  Gejrman 
built  Shuttle  Pallet  Satellite  (SPAS)  contained  a  German  made 
space  qualified  GPS  receiver.  The  ORFEUS/SPAS  GPS  unit  was 
used  to  provide  state  vector  information  in  its  telemetry.  The 
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SPAS  state  vector  Information  was  then  retrieved  from  the  128 
Kbyte  data  link  streaun  for  use  in  the  NPS  software. 

2 .  Software  Component e 

a.  PC  Decommitatx>r  (PCDecom) 

The  PC  Decommutator  (PCDecom)  software  package 
written  by  Tom  Silva  of  The  Telemetry  Workshop  resided  in  the 
GRID  1535  PGSC.  PCDecom  is  capable  of  reading  data  from  the 
128  Kbyte  data  streaim,  displaying  selected  data  to  the  GRID 
1535  PGSC  display  screen,  and  packetizing  desired  data  for 
serial  transmission  to  other  users.  For  DTO  700-6,  PCDecom 
transmitted  data  packets  containing  Orbiter,  SPAS  target,  and 
SPAS  GPS  state  vectors  as  well  as  the  Orbiter' s  quaternion  to 
the  GRID  1530  via  an  RS-232  port  for  use  by  the  NPS  software. 

b.  TANS  Software 

The  TANS  GPS  software,  or  level  I  code, 
communicated  with  the  TANS  unit,  displayed  various  TANS  GPS 
data  on  the  GRID  1530  PGSC  display  screen,  converted  the  TANS 
GPS  state  vector  from  WGS-84  Earth- centered.  Earth -fixed 
(ECEF)  coordinates  to  M-50  inertial  coordinates,  and  provided 
the  M-50  GPS  state  vector  data  to  the  NPS  software. 

c.  NPS  Software 

The  NPS  software,  or  level  II,  III,  and  IV  code, 
processed  incoming  state  vectors  for  display  on  relative 
motion  plots  and  state  vector  difference  plots.  The  NPS 
software  was  run  independently  as  a  stand  alone  program  when 


TANS  GPS  data  was  unavailable  during  shuttle  flight 
simulations  prior  to  the  launch  of  STS- 51,  and  as  a 
subordinate  function  to  the  TANS  GPS  level  I  code  during  the 
STS- 51  mission.  Details  of  the  NPS  software  are  contained  in 
the  Chapters  V,  VI,  and  VII.  Further  information  is  contained 
in  the  User's  Guide  in  J^pendix  B. 

The  relationship  between  the  hardware  and  software 
components  of  this  experiment  is  illustrated  in  Figure  2-1. 
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Figure  2-1.  DTO  Eardware/Softwere  Cooponenta. 
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III.  UIATIVI  MOTIOV  AMD  PL0TTIH6 


The  STS- 51  mission  objectives  included  the  use  of  the  TANS 
GPS  receiver  to  obtain  GPS  data  on  orbit,  and  the  deployment 
and  recovery  of  the  ORFEUS/SPAS  satellite.  These  events 
provided  unique  opportunities  to  test  features  of  the  NPS 
software  relative  motion  plotting  functions  and  fulfill  the 
level  III/IV  objectives  of  DTO  700-6,  specifically  evaluating 
relative  GPS  navigation  for  satellite  rendezvous  and 
displaying  in  real  time  the  rendezvous  profile. 

To  appreciate  the  capedjilities  of  the  NPS  software  and  its 
employment,  a  basic  understanding  of  spacecraft  relative 
motion,  relative  motion  plotting,  and  Orbiter  separation, 
rendezvous,  and  proximity  operations  is  necessary.  The 
following  description,  while  by  no  means  complete,  serves  to 
provide  the  background  to  understand  the  NPS  software's  use 
during  the  STS -51  mission. 

A.  RBLATIVB  MOTION  PLOTS  (R-BAR/V-BAR) 

The  concept  of  relative  motion  between  a  target  vehicle 
and  a  chaser  vehicle  in  space  is  complicated  by  the  lack  of  a 
constant  reference  when  viewed  in  an  inertial  frame.  To 
simplify  the  presentation  and  explanation  of  relative  motion, 
the  relative  motion  plot  uses  a  local  vertical,  circular  (LVC) 
coordinate  system.  The  LVC  coordinate  system  is  target - 
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centered.  The  Z-aucis  rotates  with  the  target  and  is  positive 
directed  radially  toward  the  Earth  (R-bar) .  The  X-axis  is 
curvilinear  and  positive  in  the  general  direction  of  orbit 
motion  (V-bar) .  The  Y-axis  is  normal  to  the  target's  orbital 
plane  and  con^letes  the  right-hand  coordinate  system.  The  R- 
bar/V-bar  plot  displays  the  relative  motion  between  a  target 
and  a  chaser  vehicle  in  LVC.  This  system  is  the  one  used  by 
NASA  in  planning  shuttle  Orbiter  rendezvous  and  proximity 
operations.  (Figure  3-1.) 

Tar^ 

vahid* 


Figure  3*1.  Relative  motion  plot  definition. 

R-bar  displacement  is  measured  positively  towards  the 
Earth  and  represents  an  altitude  difference  between  the  target 
and  the  chaser.  V-bar  displacement  is  measured  positively  in 
the  target's  direction  of  travel  and  represents  the  phase 
difference  between  the  target  and  the  chaser.  Thus,  if  the 
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chaser  were  directly  below  the  target  on  the  radius  vector  to 
the  Earth's  center,  it  would  appear  on  the  *Z  axis  (R-bar)  of 
the  relative  motion  plot.  Similarly,  if  the  chaser  was  ahead 
of  the  target  on  the  target ' s  orbital  path  and  at  the  targets 
altitude,  it  would  appear  on  the  +X  axis  (V-bar)  on  the 
relative  motion  plot. 

B.  SINGLE  nfPULSB,  IN  PLANE,  ORBITAL  MANEOVERS 

The  following  maneuvers  are  the  fundamental  building 
blocks  of  rendezvous  and  proximity  operations.  The  resulting 
motions  described  assume  the  Orbiter's  initial  position  is  co¬ 
located  with  a  non -maneuvering  target  and  in  a  co-planer  orbit 
in  order  to  provide  a  reference  point  to  measure  motion 
against . 

1.  Poslgrade  Bum 

A  posigrade  burn  is  one  in  which  the  thrust  is  in  the 
direction  of  the  velocity  vector.  A  posigrade  burn  increases 
the  energy  of  the  orbit,  increases  the  semi  major  axis  and  the 
angular  momentum,  and  increases  the  period  of  the  orbit.  For 
a  near  circular  orbit,  a  posigrade  burn  will  raise  every  point 
of  the  orbit  except  the  thrust  point.  For  example,  if  the 
orbit  was  originally  circular,  a  posigrade  maneuver  will 
create  an  elliptical  orbit,  with  the  thrust  point  becoming 
perigee  and  apogee  occurring  180  degrees  of  orbit  travel 
away.  [Ref .  2:  p.  1-11]  Results  of  a  posigrade  burn  will  be 
separation  from  the  target  along  the  negative  V-bar. 
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2 .  Rtttrograd*  Burn 

A  retrograde  bum  is  one  in  which  the  Lhmst  is 
opposed  to  the  direction  of  the  velocity  vector.  A  retrograde 
bum  decreases  the  energy  of  the  orbit,  decreases  the  semi- 
major  eucis  and  the  angular  momentum,  and  decreases  the  period 
of  the  orbit.  For  a  near  circular  orbit,  a  retrograde  burn 
will  lower  every  point  of  the  orbit  except  the  thrust  point. 
For  excunple,  if  the  orbit  was  originally  circular,  a 
retrograde  maneuver  will  create  an  elliptical  orbit,  with  the 
thrust  point  becoming  apogee  and  perigee  occurring  180  degrees 
of  orbit  travel  away. [Ref.  2;  p.  1-15]  Results  of  a  retrograde 
burn  will  be  separation  from  the  target  along  the  positive  V- 
bar . 

3 .  Radial  Bum 

A  radial  burn  is  one  in  which  the  thmst  is  applied  in 
a  direction  perpendicular  to  the  spacecraft's  velocity  vector 
and  in  the  orbital  plane  of  the  spacecraft. [Ref .  2;  p.  1-18] 
Radial  burns  result  in  a  'fly-around'  maneuver.  That  is,  to  an 
observer  on  the  target,  it  appears  as  if  the  chaser  vehicle 
flies  in  an  ellipse  whose  path  size  is  dependent  on  the 
magnitude  of  the  burn  and  whose  period  is  equal  to  the  orbital 
period  of  the  chaser  vehicle. 

Figure  3-2  illustrates  the  resultant  relative  motion  of  a 
chaser  vehicle  performing  posigrade,  retrograde,  and  radial 
burn  maneuvers  (1  ft/s  bums)  with  respect  to  a  target 
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vehicle.  Both  vehicles  are  initially  colocated  and  in 
circular  orbits. 

C.  RBMDBZVOnS  MMISaVBR  SBOOBTCH 

The  rendezvous  is  the  act  of  bringing  two  vehicles 
together.  Considerations  for  rendezvous  are  numerous  and 
include  orbital  parameters  such  as  altitude,  phasing,  and 
inclination.  The  lighting  conditions  are  also  of  in5)ortance  as 
the  rendezvous  must  be  conducted  in  the  light  and  star 
tracking  of  the  target  requires  that  it  be  illuminated. 
Depending  on  the  mission,  the  rendezvous  sequence  can  begin  as 
early  as  launch  time.  For  the  STS-51  SPAS  mission,  rendezvous 
commencement  was  from  the  negative  V-bar,  hence  only  maneuvers 
relevant  to  rendezvous  from  near  co-altitude,  co-planer  orbits 
will  be  discussed. 

1.  Phase  Adjustment  Maneuvers 

The  phase  adjustment  maneuver,  or  nominal  correction 
(NO,  is  used  to  adjust  the  'catchup'  rate  of  the  Orbiter  to 
the  target.  This  is  performed  by  raising  or  lowering  the  semi- 
major  eucis  through  a  posigrade  or  retrograde  maneuver.  The 
nominal  correction  maneuver  is  ground  targeted. 

2.  Corrective  Conblnation  Maneuvers 

The  nominal  corrective  combination  (NCC)  maneuver  is 
the  first  onboard  targeted  bum  based  on  onboard  sensor  data 
such  as  the  star  tracker  or  rendezvous  radar. 
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3.  T^ninal  Initiation 

The  terminal  initiation  (TI)  bum  alters  the  approach 
from  one  of  phasing  to  one  of  direct  intercept.  TI  occurs 
approximately  one  revolution  prior  to  intercept. 

4 .  Midcourse  Correction 

The  midcourse  correction  (MC)  maneuvers  are  performed 
to  ensure  correct  trajectory  from  TI  to  target  intercept.  Four 
MC  burns  were  planned  during  the  final  revolution  of  the 
rendezvous . 

The  scheduled  rendezvous  maneuvers  were  designed  to 
conclude  with  the  Orbiter  in  a  stable  position  400  feet  in 
front  of  the  target  on  the  V-bar.  The  final  approach  to  the 
target  is  included  in  proximity  operations  maneuvering. 

D.  PROXIMITY  OPERATIONS 

Proximity  Operations  (PROX  OPS)  consist  of  several  types 
of  maneuvers  including  close  in  station  keeping,  separation 
maneuvering,  and  final  approaches  to  the  target. 

1.  Station  Keeping 

Station  keeping  is  performed  by  matching  the  target 
orbital  plane  and  altitude.  When  precise  station  keeping  is 
not  required,  as  is  the  case  when  the  target  is  being  held  at 
some  stand-off  distance,  local  phasing  or  fly-around  maneuvers 
can  be  executed  to  maintain  station. 
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2.  Separation  Manauvars 


Separation  from  the  target  can  be  achieved  by  means  of 
a  posigrade  or  retrograde  burn,  a  radial  burn,  or  by  a 
combination  of  these.  A  separation  maneuver  is  referred  to  as 
a  SEP  burn. 

3.  J4>proach  To  Target 

While  there  is  no  standard  rendezvous  procedure 
applicable  to  all  situations,  three  methods  of  approach 
technique  have  been  studied  with  respect  to  operations 
feasibility,  propellant  consumption,  and  plume  impingement. 
The  techniques  are  (1)  the  direct  approach,  (2)  the  V-bar 
approach  (from  behind  or  ahead),  and  (3)  the  R-bar  approach 
(from  above  or  below) . [Ref.  2:  p.  4-10]  The  STS-51  mission 
profile  called  for  a  positive  V-bar  approach  and  an 
explanation  of  this  method  is  in  order. 

The  positive  V-bar  approach  is  initiated  by 
establishing  a  closure  rate  toward  the  target  via  a 
combination  retrograde/radial  outward  burn.  This  results  in  a 
'hop'  on  the  V-bar  toward  the  target.  With  no  further  thruster 
inputs,  the  trajectory  would  fall  below  the  V-bar  and  the 
Orbiter  would  move  ahead  and  away  from  the  target.  As  the 
Orbiter  crosses  the  V-bar,  a  radially  outward  directed  burn 
from  the  primary  reaction  control  system  (PRCS)  raises  the 
Orbiter  slightly  above  the  V-bar,  allowing  the  Orbiter  to  slow 
down  and  close  with  the  target  further.  This  sequence 
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continues  until  the  target  is  intercepted,  where  a  braking 
maneuver  nulls  the  closure  rate  and  stcUDilizes  the  Orbiter 
with  respect  to  the  target.  (Figure  3-3.) 


IV.  MISSION  DISCRIPTION 


A.  MISSION  OVBRVIIN 

The  STS- 51  mission  objectives  included  the  use  of  the  TANS 
GPS  receiver  to  obtain  Orbiter  GPS  data  on  orbit,  and  the 
deployment  and  recovery  of  the  GPS  equipped  ORFEUS/SPAS 
satellite.  These  events  provided  unique  opportunities  to  test 
features  of  the  NPS  software  relative  motion  plotting 
functions  and  fulfill  the  objectives  of  DTO  700-6. 

B.  STS- 51  MISSION  TIME  LIMl 

The  STS- 51  planned  mission  profile  events  pertaining  to 
DTO  700-6  and  related  events  such  as  SPAS  deployment  and 
retrieval  are  described  in  [Ref.  3]  and  were  as  follows: 

Flight  day  one  -  The  DTO  hardware  components  (TANS  GPS 
receiver,  GRID  1530/1535  PGSC's,  antennas,  etc)  were  assembled 
in  Discovery's  flight  caibin. 

TANS  GPS  data  recording  was 
initiated. 


Flight  day  two  SPAS 
deployment  and  separation  was 
achieved.  Through  a  series  of 
three  separation  (SEP)  bums. 
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Discovery  was  moved  away  from 
the  SPAS  along  the  V-bar  by 
means  of  poslgrade  aind 
retrograde  thrusts.  Initial 
separation  was  acccm^lished 
at  the  SEP  1  (retrograde) 
burn.  (Figure  4-1.,  Tad>le  4- 
1 . )  The  Orblter  arrived  at 
the  positive  V-bar  after  one 
revolution.  A  poslgrade  bum 
was  performed  to  null  rates 
and  allow  V-bar  station 
keeping.  The  SEP  2 
(poslgrade)  carried  Discovery 
over  the  top  and  behind  SPAS. 
(Figure  4-2.)  At  V-bar 
crossing,  the  SEP  3 
(retrograde)  burn  was 
performed  and  the  Orblter 
advanced  to  a  station  keeping 
position  on  the  V-bar  between 
•t-13  and  +20  nml.  Nominal 
Correction  (NC)  1  was 
performed  at  this  time  and 
Discovery  maintained  station 


Figure  4-2.  SIP  1  and  SIP  2 
bums 
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rigur«  4-3.  SIP  3  aanmv^r  to  V-bar  station  kaaping. 


Flight  day  alx  -  NC  ll  phasing  maneuver  (posigrade)  was 
performed.  Discovery  maneuvered  towards  and  over  the  top  of 
the  SPAS  to  take  up  a  station  keeping  position  on  the  V-bar  at 
-10  to  -17  nmi.  (Figure  4-4.) 


Flight  day  aight  -  The  rendezvous  maneuver  was  performed.  A 
posigrade  phasing  maneuver  moved  the  Orbiter  frcxn  station 
keeping  to  approximately  -30  nmi  on  the  V-bar.  A  second 
retrograde  phasing  maneuver  initiated  the  three  revolution 
approach  to  intercept.  This  was  followed  by  target  acquisition 
with  the  Orbiter' s  star  tracker,  a  relative  navigation  update, 
and  the  NCC  burn.  The  rendezvous  radar  acquired  the  target  at 
approximately  two  revolutions  out.  At  V-bar  crossing,  one 
revolution  prior  to  intercept,  the  TI  bum  occurred.  In  the 
final  orbit  of  the  approach,  four  MC  maneuvers  were  performed 
to  ensure  the  Orbiter  arrived  slightly  aUaove  the  v-bar 
approximately  400  feet  ahead  of  the  target.  From  here  a 
positive  V-bar  approach  (discussed  previously  in  chapter  III) 
was  planned  to  coir^lete  the  intercept.  (Figure  4-5.) 


Figure  4-5. 


Flight  day  nine  -  Disassembly  and  storage  of  DTO  hardware  was 
conqpleted  in  preparation  for  return  to  Earth. 
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V.  II»S  SOPTNMtS  ARCHITBCTOBS 


A.  NFS  SOFTHARB  DISIOM  PBZLOSOPEY 

The  NPS  software  architecture  design  is  an  event  driven 
architecture.  The  NPS  software  must  collect  data  from  multiple 
sources  such  as  communications  ports  or  files,  process  data, 
control  the  screen,  and  respond  to  keyboard  inputs.  The 
program  cannot  be  dependent  on  any  single  event  occurring  such 
as  might  be  required  in  a  loop.  The  NPS  software  must  poll  the 
data  source,  then  continue  with  its  other  tasks  or  return 
control  to  the  calling  routine.  The  progreun  must  handle 
keyboard  interimpts  without  losing  input  data.  It  must  be 
robust  enough  to  handle  partial  data  packets  or  suspension  of 
data  transfer  without  crashing. 

The  NPS  software  is  organized  on  several  levels.  Data 
types  used  by  the  system  are  organized  into  a  hierarchy  of 
data  structures  for  program  efficiency  and  readcdsility .  The 
code  is  organized  into  a  versatile  toolbox  of  functions  that 
allow  for  flexibility  in  progreunming  and  usage.  The  file 
system  is  organized  for  ease  of  editing  functions,  adding  new 
functions  or  files,  and  compiling  the  code. 

B.  DATA  STRUCTORBS 

The  NPS  software  was  designed  to  run  on  the  GRID  1530 
PGSC,  a  10  MHz  80386  portcdsle  con^uter.  The  slow  clock  speed. 
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combined  with  high  data  rates  and  ccxiputationally  intensive 
orbit  propagation,  necessitated  an  efficient  code  in  order  to 
ensure  no  loss  of  data. 

In  order  to  minimize  the  time  spent  passing  large  data 
structures  (such  as  a  state  vector  which  contains  56  bytes) 
around  between  functions,  the  NPS  software  maximizes  the  use 
of  pointers  to  access  data  structures.  Sinply  passing  the 
pointer  to  a  structure  into  a  function  allows  access  to  the 
entire  structure  in  the  function  by  referring  to  the  memory 
address  of  the  structure. 

Efficient  use  of  structures  internal  to  the  NPS  software 
allow  single  functions,  such  as  plotting  routines,  to  be  used 
for  multiple  combinations  of  inputs,  adding  flexibility  to  the 
code  and  reducing  the  executeible  file  size.  For  example,  there 
is  only  one  R-bar/V-bar  plotting  function.  However,  this  one 
function  is  able  to  display  six  distinct  plots  simply  by 
calling  the  function  with  pointers  to  structures  containing 
the  plot  data,  titles,  scales,  and  ring  buffer  files  for  the 
individual  plot  desired. 

Some  defined  structures  are  used  for  editing  screens.  An 
editing  screen  allows  the  operator  to  manually  input  or  modify 
program  variables  such  as  state  vectors  or  function  toggle 
switches.  Again,  the  use  of  pointers  to  structures  containing 
edit  information  is  a  flexible  and  efficient  way  of 
programming . 
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Several  types  of  structures  have  been  created  for  use  in 
programming.  These  include  sinqple  structures  and  coir^lex 
structures.  A  single  structure,  such  as  the  Vector  structure, 
consists  of  three  doubles  (double  precision  floating  point 
number,  8  bytes  each),  x,  y,  and  z.  A  complex  structure,  such 
as  the  State_vector  structure,  contains  two  Vector  structures 
and  a  double  for  time.  The  structure  data  types  used  by  the 
NPS  software  are  defined  here. 

1.  Vector  Structtire 

A  Vector  structure  consists  of  three  doubles  (8  bytes 
each),  X,  y,  and  z.  Vectors  are  used  in  complex  structures 
such  as  State_vectors  and  independently  throughout  the  code. 

2 .  State_vector  Structure 

The  State_vector  structure  contains  two  Vector 
structures,  representing  position  and  velocity,  and  a  double 
representing  time.  State_voctors  are  the  primary  information 
source  the  NPS  software  was  designed  to  examine. 

3 .  RV_vector  Structure 

The  RV_vector  structure  contains  a  position  Vector 
structure  and  a  double  representing  time.  An  RV_vector 
contains  the  coordinates  of  the  Orbiter  with  respect  to  the 
target  in  the  R-bar/V-bar  coordinate  system. 

4.  Dlff_vector  Structure 

The  Diff_vector  structure  contains  an  array  of  two 
doubles,  the  difference  of  the  magnitudes  of  two  state 
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vector's  position  and  velocity  vectors,  and  a  double 
containing  time. 

5 .  Quaternion  Structure 

A  Quaternion  structure  contains  five  doubles,  gi,  g2, 
g3,  g4,  and  time.  A  Quaternion  is  a  four  parameter 
representation  of  a  transformation  matrix.  It  provides  a 
numerical  relationship  between  coordinate  frames.  Quaternions 
are  used  due  to  their  convenient  small  size;  that  is,  four 
parameters,  as  opposed  to  nine  parameters  in  a  transformation 
matrix  (or  direction  cosine  matrix) . [Ref.  4,  p  l-l]  The 
relationship  between  the  Orbiter  body  and  M-50  (Aries -mean- of - 
1950  Cartesian  coordinate  system)  inertial  coordinate  frames 
comes  into  the  NFS  software  as  a  quaternion.  The  quaternion  is 
then  converted  into  a  direction  cosine  matrix  for  use  in  the 
program.  Quaternion  algebra  is  not  used  in  the  NFS  software. 

6 .  Packet  Structures 

State  vectors  and  various  other  information  are  passed 
into  the  NFS  system  in  the  form  of  data  pac)cets.  A  data  pac)cet 
is  a  structure  consisting  of  several  other  structures 
including  a  Packet_header  structure,  packet  specific 
information,  and  a  Packet_trailer  structure.  There  are  three 
types  of  packets,  (1)  the  Orb_j;>acket  (Orbiter  packet)  ,  (2)  the 
Spa8_packet  (SPAS  packet)  ,  and  (3)  the  0rb_gp8_packet  (Orbiter 
GPS  packet) .  The  Orb_packet  contains  aui  Orbiter  State_vector 
structure,  Orbiter  Quaternion  structure,  lCO_info  structure. 
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and  target  State_vector  structure.  The  Spa8_packet  contains 
the  SPAS  State_vector  structure.  The  0rb_gp8_packet  contains 
the  Orbiter  TANS  GPS  State_vector  structure. 

The  inj_info  structure  was  included  to  allow  input  of 
information  relating  to  the  KU-band  radar  used  for  approach 
and  rendezvous.  This  structure  was  not  utilized  for  STS -51.  It 
was  retained  for  possible  future  use. 

7 .  Nps_stata_vector_lnfo  Structure 

The  Nps_state_vector_in£o  structure  contains  the  input 
8tate_vector  structure,  a  second  'copy'  state_vector 
structure,  and  various  administrative  flags  and  time  markers 
u£?et  the  program  to  organize  the  information  known  about  a 
given  state  vector.  The  original  input  state  vector  is  never 
altered  in  the  NPS  system.  Only  the  'copy'  is  manipulated  or 
propagated.  This  preserves  the  original  data  should  some  other 
function  or  higher  level  system  require  it. 

8 .  Nps_quaternlon_lxi£o  Structure 

The  Mp8_quatemlon_ln£o  structure  serves  the  same 
function  for  the  Quaternion  structure  as  the 
Nps_state_vector_info  structure  serves  for  the  state_vector 
structure . 

9 .  Gravlty_data  Structure 

The  gravlty_data  structure  consists  of  five  doubles 
containing  planetary  constants  such  as  Earth  radius, 
(Earth  gravitational  constant) ,  the  Earth  flattening 
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coefficient,  the  J2  zonal  harmonic  coefficient,  and  the  earth 
rotation  rate  w.  The  gravlty_data  structure  also  includes  two 
double  arrays  containing  the  GEM  9  gravity  model  sectoral  and 
tesseral  harmonic  coefficients. 

For  further  information  on  gravity  model  data,  see 
[Ref.  5:  Chapter  9]. 

10.  GravltyjBodel_data  Structure 

The  gravity jBiodel_data  structure  contains  a 
gravlty_data  structure  and  three  integers.  Two  of  the  Integers 
determine  the  nximber  of  sectoral  and  tesseral  harmonics  to  use 
in  the  gravity  model.  The  third  is  an  on/off  mode  switch. 

11.  Drag_aiodel_data  Structure 

The  drag_nodel_data  structure  consists  of  four  doubles 
defining  the  solar  flux  {F10.7),  mean  solar  flux  (F10.7^ve), 
the  Earth's  geomagnetic  index,  and  a  ballistic  number  for  the 
object  to  which  the  dragjiiiodel_data  structure  is  assigned. 

12 .  Perturbations  Structure 

The  Perturbations  structure  contains  a 
gravity_]oodel_data  structure  and  a  drag_aodel_data  structure. 
Each  propagated  object  (ie  Orbiter,  ORFEUS/SPAS)  has  its  own 
Perturbation  structure. 

13.  llps_predictor_thrust  Structure 

The  l^sjpredlctor_ thrust  structure  contains  three 
Integer  flags  indicating  the  status  (on/off)  of  the  thrust 
predictor  function  and  the  delayed  thrust  option,  and  the 


32 


LVLH/body  coordinate  switch.  This  structure  also  contains  a 
double  with  the  delayed  thruster  firing  time,  and  a  Vector 
structure  holding  the  delta-V  components  of  the  thrust. 

14.  llps_predictor  Structure 

The  Mpejpredlctor  structure  contains  a  pointer  to  the 
Perturbations  structure,  a  pointer  to  the  llp8_guatemlon_ln£o 
structure,  the  Nps_predictor_thrust  structure,  three  doubles 
containing  step  size,  delay  time  between  predictor  updates, 
and  the  time  when  the  predictor  will  execute  next.  The 
structure  also  contains  two  integers  declaring  the  number  of 
steps  to  predict  and  whether  the  function  is  active  or  not. 

15.  Nps_graphlcs_ln£o  Structure 

The  Mp8_graphlcs_ln£o  structure  contains  Integers 
defining  the  video  screen  width  and  height,  screen  center, 
font  size,  page  number  (for  text  screens) ,  and  a  text /graphics 
mode  flag. 

16.  Nps_plot_axls 

The  N!ps_plot_axls  structure  contains  two  doubles 
representing  the  axis  origin  and  the  axis  range  for  a  single 
axis  on  a  given  plot. 

17 .  Mpsjplot_ln£o  Structure 

The  Hps_plot_in£o  structure  contains  pointers  to  plot 
title  strings  and  Nps_plot_axls  structures  for  the  x  and  y 
axis . 
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18.  llps_rvplot_lnfo 

Each  R-bar/V-bar  plot  has  a  designated  Ilps_rvplot_in£o 
structure  containing  the  llpsjplot_ln£o  structure,  a  pointer  to 
the  plot  RV_vector  ring  buffer,  a  pointer  to  the  current  menu 
bar  list,  pointers  to  the  associated  state  vectors,  pointers 
to  the  associated  buffer  storage  file,  a  pointer  to  the 
llps__predlctor  structure,  and  various  plot  function  flags.  The 
plotting  function  is  called  with  this  structure  as  the  calling 
argximent.  This  permits  a  single  relative  motion  plot  function 
or  difference  plot  function  to  be  customized  to  display  any 
one  of  the  six  possible  combinations  of  desired  state  vector 
comparisons  with  appropriate  titles,  plot  scale,  and  other 
features . 

19.  llp8_di££plot_ln£o  Structure 

Each  'Sawtooth'  plot  has  a  designated 
llps_di££plot_ln£o  structure  containing  the  llps_plot_in£o 
structure,  a  pointer  to  the  plot  Di££_vector  ring  buffer,  a 
pointer  to  the  current  menu  bar  list,  pointers  to  the 
associated  state  vectors,  pointers  to  the  associated  buffer 
storage  file,  and  various  plot  function  flags.  The  plotting 
function  is  called  with  this  structure  as  the  calling 
argument.  This  permits  a  single  difference  plot  function  to  be 
customized  to  display  any  one  of  the  four  possible 
combinations  of  desired  state  vector  comparisons  with 
appropriate  titles,  plot  scale,  and  other  features. 
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20.  ll!pa_pyplot_lnfo  Structur* 

Each  Pitch/Yaw  plot  has  its  own  ll!ps_pyplot_lnfo 
structure  containing  title  strings  and  a  pointer  to  the  menu 
structure.  The  Pitch/Yaw  function  is  called  with  this 
structure  as  the  calling  argument.  This  permits  a  single 
Pitch/Yaw  plot  function  to  be  customized  to  display  pitch/yaw 
information  based  on  any  one  of  the  three  possible 
combinations  of  source  state  vectors  with  appropriate  titles. 

21.  Mps_fllter_ln£o  Structure 

The  Np8_£llter_ln£o  structure  contains  integers, 
doubles,  and  Vectors  used  for  initializing  and  maintaining  the 
GPS  Filter  function  and  its'  ring  buffer. 

22.  Tlme_dh]ii8  Structure 

The  Tlae_dhas  structure  contains  unsigned  short 
integers  for  the  day  of  the  year,  and  the  hours,  minutes, 
seconds,  and  milli- seconds  past  midnight. 

23.  Bdlt_label  Structure 

The  Sdit_label  structure  contains  two  integers,  the 
text  screen  row  and  column  location  of  the  edit  field  title, 
and  a  pointer  to  the  character  string  contairing  the  edit 
field  title. 

24.  Edlt_£leld_ln£o  Structure 

The  Edit_£ield_in£o  structure  defines  the  edit  field 
string  location,  flags,  size,  and  cursor  offset. 
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25.  ■dit_fl«ld  Structur* 

The  Kdlt_fl«ld  structure  defines  screen  location,  data 
location,  and  field  edit  routines  for  a  single  edit  field. 

26.  Current_field  Structure 

The  current_field  structure  contains  pointers  to  the 
Bdlt_field  and  Bdit_field_in£o  structures  currently  in  use. 

27 .  Bdlt_screen  Structiure 

The  Bdlt_screen  structure  contains  Bdit_label  and 
Bdlt_£ield  structures  that  make  up  an  individual  edit  screen 
and  the  current_£leld  structure.  The  Bdlt_screen  structure 
also  contains  pointers  to  data  used  by  edit  screen  processing 
routines. 

C.  PROGRAM  ARCBITBCTURB 

The  NPS  software  is  not  a  single  progreun.  It  is  a 
collection  of  functions  that  can  be  mixed  and  matched  to 
create  specific  applications  using  the  NPS  relative  motion 
plotting  and  state  vector  analysis  routines.  One  version  of 
the  code  might  read  its  input  from  multiple  communications 
ports  (ie  the  flight  version)  while  another  version  acquires 
its  input  from  data  files  (ie  for  post-flight  analysis  of 
recorded  data) .  An  all  encompassing  'Do-it-all'  version  was 
undesirable  due  to  size  limitations  on  the  executable  size  of 
the  program. 

The  versions  of  most  interest  are  the  NPS  'stand-alone' 
flight  version  and  the  TANS  GPS/NPS  integrated  version  as 


36 


these  were  the  versions  flo%m  on  STS- 51.  Two  other  versions  of 
interest  are  the  'simulator'  version,  which  creates  its  o%m 
state  vector  inputs  in  realtime  and  is  used  for  progreun 
testing,  and  the  'replay'  version,  which  plays  back  recorded 
data  (real  or  simulated) .  Despite  the  variety  of  possible 
combinations,  all  variants  of  the  program  contain  a  common 
architecture.  An  understanding  of  one  yields  an  understanding 
of  the  others. 

1.  The  'Main'  Function 

All  'C'  progreuns  must  have  a  'main'  function  from 
which  to  begin.  The  NFS  software  is  no  different.  An  important 
feature  of  the  NFS  software  is  that  it  does  not  matter  where 
the  'main'  function  is  or  what  it  does,  only  that  it  calls  the 
appropriate  NFS  software  subfunctions. 

From  the  'main'  function  the  data  source  is 
initialized.  The  source  could  be  a  data  port  or  other  device, 
a  file,  or  another  simulator  function.  The  NFS  software  does 
not  care  where  the  data  comes  from,  only  that  it  is  in  the 
appropriate  format. 

Following  data  source  initialization,  the  NFS  system 
is  initialized.  System  initialization  includes  the  following: 
(1)  opening  and  reading  configuration  files  containing  memory 
setup  data,  lERS  data,  and  plot  history  files,  (2)  memory 
setup,  (3)  plot  ring  buffer  initialization,  (4)  graphics 
driver  initialization,  and  (5)  keyboard  handler  designation. 
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At  this  point,  the  'main'  function  enters  an  infinite 
loop  of  updating  the  NPS  data  buffers  and  awaiting  keyboard 
commands.  The  NPS  system  is  running  and  processing  incoming 
data  regardless  of  whether  or  not  the  plotting  screens  are  up. 
Control  of  the  program  resides  with  the  controlling  keyboard 
handler.  The  'main'  routine  has  a  keyboard  handler  and  the  NPS 
progrcun  has  a  keyboard  handler.  When  the  'main'  program  is 
initiated,  program  control  is  held  by  the  'main'  keyboard 
handler.  Control  is  passed  to  the  NPS  keyboard  handler  upon 
selection  of  the  NPS  system.  Both  systems,  the  calling  'main' 
prograun  and  NPS,  are  still  running,  only  now  the  NPS  keyboard 
handler  controls  the  program  and  will  only  respond  to  NPS 
system  assigned  key  strokes.  Escaping  from  the  NPS  system 
passes  keyboard  control  back  to  the  calling  program  but  does 
not  terminate  calls  to  the  NPS  software  for  data  updates. 

Upon  'main'  prograun  termination,  the  NPS  system  is 
gracefully  exited.  This  includes  storage  of  plot  history  files 
for  future  recall  and  the  properly  closing  out  of  the  data 
sources  (ie  files,  ports,  etc.). 

2.  K«^>oard  Control 

Control  of  the  program  resides  with  the  keyboard 
handler.  The  main  routine,  which  may  be  a  program  like  the 
TANS  GPS  program  in  the  integrated  version,  the  simulator 
propagator  in  the  simulator  version,  or  simply  a  shell  prograun 
that  does  nothing,  has  a  keyboard  handler.  This  'main' 
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keyboard  handler  takes  control  of  the  keyboard  upon  start-up 
of  the  'main'  prograun.  Control  is  passed  to  the  NPS  keyboard 
handler  upon  selection  of  the  NPS  system.  Both  the  main 
prograun  and  the  NPS  software  as  a  lower  level  system  are  still 
running,  only  now  the  NPS  keyboard  handler  controls  the 
keyboard  and  will  only  respond  to  recognized  key  strokes 
assigned  by  the  NPS  software.  Escaping  from  the  NPS  system 
passes  keyboard  control  back  to  the  calling  prograun  but  does 
not  terminate  calls  to  the  NPS  software  for  data  updates. 

As  an  exaunple  of  prograun  architecture,  in  the  TANS  GPS/NPS 
integrated  flight  version  of  the  prograun,  the  'main'  function 
is  the  TANS  GPS  program.  The  TANS  GPS  prograun  performs  the 
functions  of  communicating  via  the  RS-422  port  with  the  TANS 
GPS  unit,  collecting  and  storing  of  TANS  GPS  data,  and 
presentation  of  TANS  GPS  data,  as  well  as  the  NPS  input  port 
and  system  initialization,  and  updating  the  NPS  system  with 
TANS  GPS  state  vectors.  When  TANS.EXE  is  executed,  the  TANS 
GPS  program  is  displayed  and  the  TANS  GPS  keyboard  handler  is 
in  control.  The  NPS  system  is  running  but  is  not  observed 
until  the  NPS  function  key  in  the  TANS  GPS  keyboard  handler  is 
selected.  At  this  time  the  NPS  software  displays  are  shown, 
the  NPS  keyboard  handler  takes  control,  and  the  program 
responds  to  all  NPS  software  system  commands.  The  TANS  GPS 
program  is  still  collecting  and  storing  TANS  data  and 
performing  it's  other  necessary  functions.  Exiting  the  NPS 
system  returns  the  display  and  keyboard  control  to  the  TANS 
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GPS  prograun  but  does  not  Interrupt  the  flow  of  data  to  the  NPS 
system. 

D.  UPS  SOFTIOkU  PZLI  DZRICTO&T  OSOMtZSJlTZQV 

The  NPS  software  files  are  organized  into  a  main  directory 
with  subdirectories.  Files  are  located  in  subdirectories  by 
subject.  A  Borland  C++  'makefile'  is  used  for  coo^iling  the 
various  versions  of  the  code.  The  'makefile'  utilizes  the 
filing  system  described  here  to  optimize  compiling  time. 

The  main  directory  name  is  arbitrary  and  referred  to  as 
the  '1IPS_51'  directory  for  the  purpose  of  this  report. 
Subdirectories  included  in  the  NPS_51  directory  are  HPS, 
NPS_SIM,  TANS,  TANS^SZM,  OBBMICHl,  XITZL,  UtC,  COM,  TEST,  and 
OBJ. 

The  IIPS_51  directory  contains  the  program  executaible 
files,  the  current  International  Barth  Rotation  Service  (lERS) 
data  file,  configuration  files  and  graphics  drivers  required 
by  the  program,  and  the  'makefile'  used  for  program 
compilation.  The  NPS_51  directory  will  also  include  several 
'.nps'  files  created  by  the  NPS  software  for  storing  plot 
information.  Files  contained  in  the  HPS_51  directory  are  the 
only  files  necessary  to  run  the  program.  Files  contained  in 
all  subdirectories  are  only  required  for  source  code 
excunination,  program  compiling,  or  modification. 
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The  KPS  subdirectory  contains  source  code  directly  related 
to  the  NPS  Relative  Motion  Plotting  and  State  Vector  Analysis 
Program  and  subfunctions  available  to  the  NPS  program. 

The  MPS_SIM  subdirectory  contains  source  code  for  the 
shell  prograuns  of  the  various  versions  of  the  prograuns.  These 
shell  programs  call  the  appropriate  initialization,  operation, 
and  shutdown  routines  for  the  given  version.  These  variations 
give  the  user  the  option  to  generate  simulated  state  vectors 
and  provide  them  to  the  prograum  for  program  simulation, 
generate  state  vectors  and  send  them  to  a  file,  communications 
port,  or  device,  and  to  read  simulated  or  actual  state  vectors 
from  a  file,  communications  port,  or  memory  into  the  NPS 
prograun. 

The  ORBlfBCHl  subdirectory  contains  source  code  for  the 
Cowell  propagator.  This  propagator  includes  M-50  to  WGS-84  and 
WGS-84  to  M-50  coordinate  system  transformations,  Jacchia 
atmosphere  model  and  data  files,  the  WGS-84  gravity  model  and 
forcing  functions,  and  the  Runge-Kutta  fourth  order 
integrator.  The  Cowell  propagator  was  provided  as  an  'off-the- 
shelf'  tool  by  the  MacDonnell  Douglas  Corporation  for  DTO  700- 
6 .  The  internal  structures  and  programming  architecture  of  the 
propagator  are  not  necessarily  the  same  as  those  used  in  the 
NPS  program. 

The  UTIL  sxibdirectory  contains  source  code  for  various 
'  .c'  and  ' .asm'  utilities  called  throughout  the  program  by 
other  functions. 
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The  THIS  and  TJUfS^SDI  subdirectories  contain  source  code 
for  the  level  I  TANS  GPS  code. 

The  ZMC  subdirectory  contains  source  code  for  'include' 
files  used  at  compile  time. 

The  TIST  subdirectory  contains  source  code  for  various 
routines  written  to  develop  or  test  segments  of  the  NFS  code. 

The  CC3II  subdirectory  contains  source  code  for 
communications  routines  used  by  the  program  for  sending  and 
receiving  data  via  the  RS- 232/422  port. 

The  OBJS  subdirectory  is  required  by  the  'makefile'  and 
becomes  the  repository  for  object  files  created  in  the 
compilation  process. 
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VZ.  PROaUtfl  FUHCTZGVS 

The  NPS  flight  and  test  software  was  developed  in  a  highly 
modular  fashion.  It  was  designed  as  a  group  of  coinnon  software 
'tools'  that  could  be  used  as  plug-in  modules.  The  functions 
available  include  the  standard  'C'  library  functions  and  an 
assortment  of  functions  specifically  designed  for  use  in  the 
NPS  software.  Because  of  the  modularity  built  into  the  NPS 
code,  the  flexibility  exists  to  replace  individual  components 
such  as  the  propagator  or  plot  routines,  should  more  efficient 
routines  be  developed  at  a  later  date,  without  making 
modifications  to  the  remainder  of  the  code. 

A.  VSCTOR/KATRZX  FOVCTZON  LZBSARY 

A  collection  of  vector  operation  tools  is  included.  These 
tools  are  used  extensively  throughout  the  code.  The  following 
are  vector  and  matrix  operators  written  for  use  in  the 
software. 

The  v«ctor_aagnitud«  function  returns  the  magnitude  of  the 
input  vector.  The  protocol  for  vector_aagnitude  is: 

double  vectorjmagnltude (Vector  *v) 

The  vector_\init  function  returns  the  unit  vector  of  the 
input  vector.  The  protocol  for  vector_unit  is: 

Int  vector  unit (Vector  *vin.  Vector  *vout) 
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The  v«ctor_dot  function  returns  the  dot  product  of  two 
input  vectors.  The  protocol  for  vector_dot  is: 

double  vector_dot (Vector  *vl.  Vector  *v2) 

The  vector_croes  function  returns  the  cross  product  of  two 
input  vectors.  The  protocol  for  vector_cross  is: 

void  vector_croe8 (Vector  *vl, Vector  *v2, Vector  *vout) 

The  vector_tranaform  function  returns  the  transformed 
vector  product  of  an  input  vector  and  a  transform  matrix.  The 
protocol  for  vector_trenefoxm  is: 

void  vector_transform (Vector  Vector  *vout, 

double  traxieformO]  [3] ) 

The  iiiatrlx_tranepo8e  function  returns  the  transpose  of  the 
input  3x3  matrix.  The  protocol  for  Batrix_tranapo8e  is: 

void  matrix_transpose (double  m_in[3]  [3], 
double  ai_out[3]  [3]) 

The  8tate_vector _ Itoljmatrix  function  returns  the  M-50 

inertial  coordinate  system  to  LVLH  coordinate  system  matrix 
for  the  given  input  state  vector.  The  protocol  for 
8tate_vector _ ltol_matrlx  is : 

int  state_vector _ itol_matrix(State_vector  *8v, 

double  awtrix[3]  [3]) 

In  addition  to  these  useful  operators,  the  vector_rvbar 
and  vector_diff  functions  are  used  to  nanipulate  the  output 
into  the  desired  form  for  plotting. 

The  vector_rvbar  function  produces  the  position  vector 
from  one  state  vector  (target)  to  another  state  vector 
(chaser)  .  The  inputs  are  assumed  to  be  in  GCI,  and  the  output 
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is  returned  in  the  LVLH  of  the  principle  state  vector 
(target) .  The  output  vector  is  used  by  the  relative  motion 
plot.  The  protocol  for  v«ctor_rvbar  is: 

void  vector_r>d>ar  (Vector  *targat_po8. 

Vector  * targe t_vel. 

Vector  *cha8erjpoB, 

Vector  *rv) 

The  vector_dif£  function  returns  the  difference  vector  of 
two  input  vectors.  The  difference  vector  is  used  by  the 
'Sawtooth'  plot  to  compare  state  vector  position  and  velocity. 
The  protocol  for  vector_di££  is: 

void  vector_dl££ (Vector  *vl.  Vector  *v2.  Vector  *vout) 

B.  COWELL  PROPAGATOR 

BGProp  is  a  Cowell  orbit  propagator  using  a  Runge-Kutta 
fourth  order  integrator.  BCSprop  was  originally  written  by 
Robert  Gottlieb  and  Mike  Fraietta  of  the  McDonnell  Douglas 
Corporation  for  NASA  and  was  modified  for  use  in  the  NPS 
software.  (NOTE  -  The  function  BGProp  is  not  written 
internally  with  the  same  system  of  data  structures  or 
modularity  that  exists  in  the  remainder  of  the  NPS  software.) 

BGProp  provides  high  fidelity  solutions  for  state  vector 
propagation  at  the  expense  of  heavy  computation.  The 
propagator  consists  of  an  M-50  to  WGS-84  Earth  centered  Earth 
fixed  (ECEF)  coordinate  converter,  the  GEM- 9  Earth  gravity 
model  and  a  recursive  forcing  function  routine,  the  Jacchia 
atmospheric  model,  a  Runge-Kutta  fourth  order  integrator,  and 
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a  WGS-84  to  M-50  converter.  While  it  is  not  the  intent  of  this 
paper  to  explain  the  details  of  the  Cowell  propagator,  it  is 
necessary  to  provide  some  background  of  the  components  to 
understand  its  function  in  the  NPS  software. 

1.  M-50  to  WOS-84/1fGS-84  to  M-50  Converters 

Integrating  the  equations  of  motion  requires  knowledge 

of  the  forcing  function  acting  on  the  body  being  propagated. 
The  forcing  function  is  determined  by  the  geopotential  model 
used.  For  an  assumed  spherical  Earth  (a  two  body  problem)  ,  the 
force  acting  on  an  orbiting  object  is  a  function  of  altitude 
only.  For  an  Earth  with  only  zonal  harmonics,  the  force  is  a 
function  of  altitude  and  latitude.  Either  of  these  cases  can 
be  integrated  in  inertial  coordinates  because  rotation  of  the 
Earth  does  not  enter  into  the  solution.  Tesseral  harmonics, 
however,  are  dependent  upon  longitude  and  require  knowledge  of 
ones  position  over  the  Earth  relative  to  the  Earth's 
coordinate  system.  Use  of  these  terms  requires  converting  the 
state  vector  from  M-50  inertial  coordinates  to  an  ECEF 
coordinate  system.  BGProp  refers  to  this  ECEF  coordinate 
system  as  a  WGS-84  coordinate  system. 

2.  GSM- 9  Gravity  Modal 

The  GEM- 9  gravity  model  contains  normalized  zonal  and 
tesseral  harmonic  coefficients  empirically  determined  from 
actual  satellite  orbit  tracking.  These  coefficients  are 
applied  to  a  recursive  non- spherical  Earth  potential  function 
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out  to  the  specified  number  of  harmonics  (maximum  of  30)  .  This 
forcing  function  is  used  to  solve  for  body  accelerations  which 
are  integrated  to  obtain  new  velocities.  Accuracy  and 
computation  time  for  a  propagation  increase  as  more  harmonics 
are  used.  The  gravity  model  selected  during  the  flight 
included  four  zonal  and  four  tesseral  harmonics. 

3 .  Jacchla  Atmospheric  Model 

An  atmospheric  model  is  necessary  for  drag 
determination.  There  are  many  atmospheric  models  to  chose 
from,  each  with  merits  and  limitations,  and  all  subject  to  the 
local  uncertainty  that  is  associated  with  weather  forecasting. 
For  a  study  requiring  knowledge  of  atmospheric  constituents  at 
a  specific  place  for  a  given  cunount  of  time,  a  highly  accurate 
model  is  desired.  For  the  purpose  of  low  Earth  orbit  drag 
determination,  where  the  body  is  moving  rapidly  through  the 
upper  atmosphere  and  the  average  drag  over  a  time  period  is 
desired,  a  'good'  fast  model  will  suffice. 

The  Jacchia  '70'  atmospheric  model  contained  in  this 
code  considers  factors  including  latitude,  longitude, 
altitude,  time  of  the  year  and  local  time  of  day,  solar 
activity  and  the  Earth's  geomagnetic  activity  and  uses  this 
information  to  modify  precomputed  densities  contained  in 
tabular  form.  The  result  is  a  fast  atmospheric  density 
computation  that  approximates  that  density  encountered  by  the 
orbiting  body  as  it  circles  the  globe. 
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The  coded  Jacchia  70  atmospheric  model  is  limited  to 
use  between  90  and  500  km  altitude.  The  shuttle  typically 
flies  between  200  and  350  km.  The  STS -51  mission  flight 
profile  was  between  300  and  350  km. 

BGProp  is  called  directly  using  the  protocol : 

void  bgprop (double  8tate_vector_tiae, 

Vector  *position_ln. 

Vector  *velocity_in. 

Perturbations  *P, 
double  delta_tlme, 
double  8tep_size, 

Vector  *po8itlon_out. 

Vector  •velocity_out)  4 

or  indirectly  through  the  NPS  interface  function  nps_bgprop 
using  the  protocol ; 

int  nps_bgprop(State_vector  *sv, 
double  new_tiiiief 
int  l8_orbiter) 

C.  F  AND  G  FUNCTION  PROPAGATOR 

For  propagations  over  relatively  short  time  periods  where 
Keplerian  motion  (planer  elliptical  orbit)  is  assumed,  the  f  and 
g  functions  described  in  [Ref.  5]  produce  a  good  approximation 
of  the  orbit  motion  with  considerably  fewer  computations  than 
the  Cowell  propagator.  These  qualities  make  the  f  and  g 
functions  desirable  for  use  in  the  predictor  and  future  thrust 
functions,  allowing  fast  calculation  of  predicted  relative 
motion  into  the  near  future  (two  to  three  orbits)  without 
consuming  CPU  time  with  the  intensive  calculations  that  are 
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associated  with  the  Cowell  propagator.  The  f  and  g  functions  as 
used  in  the  NPS  software  are  described  in  [Ref.  6] . 

The  getclas  function  determines  the  classical  orbital 
elements  from  a  given  state  vector.  These  classical  elements  are 
used  by  the  f  and  g  functions.  The  protocol  for  getclas  is: 

void  getclas (Vector  *pos_o.  Vector  *vel_o, 

double  aeBoMon [5] ,  Perturbations  *P) 

The  £_and_g  function  propagates  the  input  state  vector  to  a 
given  new  time  using  the  orbital  elements  derived  in  getclas. 
The  protocol  for  £_aad_g  is: 

void  £_and_g (Vector  *pos_o.  Vector  *vel_o. 

Vector  *pos_neir.  Vector  *vel_new, 
double  clas_aeBoMon[5] ,  double  t_dl£) 

The  qulck_prop  function  is  an  implementation  of  getclas  and 
£_aad_g  and  produces  a  new  state  vector  for  the  given  state 
vector  and  new  state  vector  time.  This  function  is  an 
intermediate  function  that  allows  the  use  of  any  propagator  to 
be  substituted  for  £_and_g  without  changing  the  function  call  in 
the  calling  routine.  The  protocol  for  quick jprop  is: 

void  qulck_prop (State_vector  *old, 
double  new_tlme. 

Perturbations  *perts) 

D.  PREDICTOR  FUNCTIONS 

The  NPS  software  utilizes  the  qulck_j)rop  function  described 
previously  to  predict  where  the  Orbiter  will  be  with  respect  to 
the  target  sometime  in  the  future. 
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The  &ps_rvplot _ ^dlsplay_futur«  function  calls  the  f_and_g 

function  for  a  user  specified  number  of  times  and  step  size  for 

a  given  R-bar/V-bar  plot  in  order  to  display  a  predicted  line  of 

motion  of  the  chaser  with  respect  to  the  target.  Predicted 

motion  is  displayed  in  steps  ahead  for  the  given  step  size.  The 

first  ten  steps  are  displayed  as  digits.  For  display  of 

predicted  motion  beyond  ten  steps,  the  "+"  symbol  is  used  for 

each  step  and  digits  are  displayed  every  tenth  step.  If 

predicted  motion  based  on  user  supplied  thruster  inputs  is 

desired,  the  np8_predlctor _ thrust  function  (explained  below)  is 

called.  The  protocol  for  nps^rvplot _ display_future  is: 

void  nps_rvplot _ dlsplay_future (Mps_rvplot_in£o  *thl8) 

The  np8_pr«dletor _ thrust  function  utilizes  the  qulckjprop 

function  and  arguments  held  in  the  Hpsjpradlctor  structure  to 

add  thrust  velocity  to  the  Orbiter  state  vector  and  inclement 

the  qulck_prop  propagator  to  solve  for  the  predicted  relative 

position  of  the  Orbiter  with  respect  to  the  target.  Depending  on 

flags  contained  in  the  lilp8_pradictor  structure,  the  solution  may 

be  based  on  current  orbital  elements  of  the  target  and  chaser, 

or  on  the  orbital  motion  following  a  progreunmed  Orbiter  burn  at 

some  given  time.  To  distinguish  between  predicted  motion  without 

thrust  and  predicted  motion  with  thrust,  the  "O"  symbol  is 

substituted  for  the  "+"  for  predicted  motion  following  thrusts. 

The  protocol  for  np8_predictor _ thrust  is: 

Int  nps_pradictor _ thrust  (llp8_pradictor  *pradlctor. 

State  vector  •chaser) 
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The  np«_predlctor _ rndv  function  is  an  io^lenentation  of  the 

two  insulae  time  constrained  rendezvous  problem  described  in 
[Ref.  5,  p  179] .  The  function  determines  the  thrust  required  to 
intercept  the  target  in  a  specified  time.  The  protocol  for 
np8_predlctor _ mdv  is: 

int  zqps_predletor _ mdv(Mjps _predlctor  ^predictor, 

State_vector  *target_in, 

State_veetor  *chaser_ln, 
double  tlae_to_rendesvous) 

(NOTE  -  The  nps  predictor  mdv  function  has  been  updated  since 
the  STS-51  flight.  The  new  algorithm  is  described  in  [Ref.  6]) 

B.  PLOT/OATA  FONCTIOHS 

There  are  three  types  of  plots:  (1)  six  R-bar/V-bar  plots 
for  various  combinations  of  available  state  vectors,  (2)  four 
'Sawtooth'  plots  for  position  and  velocity  conqparisons  of 
Orbiter  INS  vs.  TANS  GPS  and  Orbiter  Target  vs.  SPAS  GPS 
sources,  and  (3)  three  Pitch/Yaw  plots  for  target  pointing 
information  based  on  various  input  state  vectors.  Each  plot  has 
common  data  handling  functions  and  plotting  functions. 

The  data  handling  functions  for  R-bar/V-bar  and  'Sawtooth' 
plots  include  a  data  initialization  function,  a  data  update 
function,  a  display  update  function,  a  data  save  function,  a 
data  flush  function,  and  a  data  stop  function.  (The  Pitch/Yaw 
plot  does  not  maintain  a  data  history  buffer,  therefore  it  only 
requires  a  display  update  function.) 
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The  data  Initialization  functions,  i»s  rvplot  data  ialt  and 
nps  ditfplot  data  init,  set  up  memory  for  the  plot  data  history 
ring  buffer  and  load  previously  stored  plot  history  files  into 

the  buffer  if  applic2d)le.  Protocols  for  nps^rvplot _ data_init 

and  nps  diffplot  data  init  are: 

Int  nps  rvplot  data  init(llps  rvplot  Info  *t2iis, 
ushort  aaxjBMS*  ushort  conflgjsm, 

Bssa  info  *«■■) 


Int  nps  diffplot  data  tnitCltes  diffplot  info  *this, 
ushort  aaxjBSSi,  ushort  conflgjiMB/ 
bn  info  *mm) 


(ushort  is  a  type  definition  for  an  unsigned  short  integer.) 
The  plot  display  initialization  functions, 

nps_rvplot _ display__init,  i^s^dlffplot _ display_init,  and 

nps_pyplot _ ^dlsplay_init,  call  several  subfunctions  responsible 

for  displaying  the  initial  plot  graphics  (axis,  menu  bars,  etc.) 
and  plotting  the  historic  data  points  stored  in  the  ring  buffer 

for  that  display.  Protocols  for  nps_rvplot _ display_init, 

nps_diffplot _ display_lnlt,  and  npsjpyplot _ dlsplay_lnit  are: 

void  zq>s_rvplot _ display_init  (llps_rvplot_inf o  *this) 

void  nps_diffplot _ display_init  (llps_dlffplot_lnfo  *this) 

void  npsjpyplot _ ^display_init  (llps_pyplot_inf o  *thls) 

The  data  update  functions,  nps  rvplot  data  update  and 
nps  diffplot  data  update,  take  the  latest  appropriate  state 
vectors,  processes  plot  information  with  either  vector_rvbar  or 
vector_diff  and  load  the  processed  plot  data  into  the  plot  ring 
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buffer.  Protocols  for  nps  rvplot  date  update  and 
nps_dl f fplot  data  update  are : 

void  OPS  rvplot  data  update  (Ups  rvplot  info  *tliis} 

void  nps_di£fplot _ data_i9date(^ps_di££plot_in£o  *this) 

The  display  update  functions.  i9S_rvplot _ ^display_update , 

np8_di££plot _ display_update.  and  nps_pyplot _ display_update , 

take  the  latest  appropriate  state  vectors,  processes  plot 
information  with  either  vector_nd»ar,  vector_di££,  or 

nps_piteli_yaw,  auid  display  the  processed  plot  data  to  the 

screen.  Protocols  for  nps_rvplot _ display _update, 

nps_di££plot _ display_t9date.  and  nps_pyplot _ display_update 

are; 

void  nps_rvplot _ display_update(lllps_rvplot__in£o  *this. 

double  target_tiaMi. 
double  chaser_tiae) 

void  nps_di££plot _ display_update(Ilps_di££plot_in£o  *thi8, 

double  targe t_tiM. 
double  ctaaser_tlaM) 

void  OPS  pyplot  display  t»date(Mps _pyplot_in£o  *thls, 
State_vector  ^target, 

State_vector  *orbiter. 

Quaternion  *quatf 
double  target_tiae. 
double  orblter_tisM) 

The  data  save  functions,  nps  rvplot  data  save  and 
nps  di££plot  data  save,  store  the  current  plot  history  ring 
buffer  to  a  file.  Protocols  for  nps  rvplot  data  save  and 
nps_di£ fplot _ data_save  are: 
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void  np«  rvplot  data  >«v(llt)a  rvplot  Info  *thla) 

void  np«_dl£fplot _ data_aavo(llp8_di££plot_in£o  *thl8) 

The  data  flush  functions,  nps_rvplot _ data_£lush  and 

npa  dittplot  data  flush,  clear  the  current  plot  history  ring 

buffer.  Protocols  for  ap8_rvplot data_£lush  and 

npa  diffplot  data  flush  are: 

void  np8_rvplot _ data_flu8h(llps_rvplot_lnfo  *thls) 

void  np8_dlffplot _ data_flu8h(llp8_dlffplot_lnfo  *this) 

The  data  stop  functions,  np8_rvplot _ data_8top  and 

npa  diffplot  data  atop,  return  the  ring  buffer  memory  reserved 
in  the  data  initialization  process  to  the  operating  system. 

Protocols  for  npa  rvplot  data  atop  and  np8_dlffplot _ data_8top 

are; 

void  nps_rvplot _ data_8top (Nps_rvplot_inf o  *thls) 

void  npa  diffplot  data  stopCMps  diffplot  Info  *thls) 

The  plotting  functions  for  each  plot  include  a  plot 
initialization  function,  various  functions  for  displaying  state 
vector  times  and  other  computed  values  such  as  distance  to 
target,  and  functions  for  displaying  plot  points  (or  lines  in 
the  case  of  the  Pitch/Yaw  plot . ) 

F.  GPS  FILTER 

The  program  contains  a  least  squares  fit  GPS  state  vector 
filter  originally  written  in  Fortran  by  Dr.  Lubomyr  Zyla  of  the 
McDonnell  Douglas  Corporation  for  NASA.  TANS  GPS  state  vectors 
provide  high  position  accuracy  on  the  order  of  a  few  hundred 
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feet.  TANS  velocity  vectors  are  not  so  accurate  with  errors  on 
the  order  of  one  meter  per  second.  For  state  vector  propagation 
over  short  periods  of  time  this  is  mauagecQ^le.  For  longer 
propagation,  the  velocity  error  can  cause  significant  errors  in 
the  propagated  state.  The  purpose  of  a  filter  is  to  'smooth'  the 
errors  in  position  and  velocity  so  that  long  propagations  may  be 
used  in  the  event  the  TANS  unit  is  switched  off  or  stops 
functioning. 

The  GPS  filter  is  a  'batch'  filter,  meaning  all  the 
operations  required  to  reach  a  solution  are  performed  each  and 
every  time  a  filtered  state  vector  is  desired.  The  filter 
maintains  a  state  vector  buffer  of  the  latest  sixty  TANS  GPS 
state  vectors.  When  activated,  the  GPS  filter  propagates 
backwards  the  latest  seven  TANS  GPS  state  vectors  through  the 
last  sixty  collected  TANS  GPS  state  vectors  with  a  high  fidelity 
propagator  (bgprop) ,  and  compares  the  outcomes  with  the  recorded 
state  vectors.  It  uses  the  results  to  determine  a  new  'smoothed' 
state  vector.  The  large  number  of  high  fidelity  propagations 
make  this  function  very  CPU  intensive. 

The  architecture  of  the  filter  code  is  similar  to  that  of 
the  plot  data  functions.  This  allows  for  the  inclusion  of 
alternate,  faster  and  more  accurate  filters  should  they  become 
available  in  the  future.  The  filter  includes  functions  for  data 
update,  data  saving,  data  flushing,  and  filter  execution. 
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The  npe  filter  data  aav  function  saves  a  state  vectors 
position  and  time  in  the  filter  data  ring  buffer.  The  protocol 
for  nps  filter  data  save  is  : 

void  nps  filter  data  savCMps  filter  info  *thl8) 

The  nps  filter  data  npdaf  function  checks  an  incoming  GPS 
state  vector  against  the  last  incoming  GPS  state  vector  to 
determine  if  it  is  a  new  state  vector.  If  it  is  new, 

nps  filter  data  save  is  called.  The  protocol  for 

nps  filter  data  update  is  : 

void  nps  filter  data  npdaf (Mps  filter  Info  *thls, 
State_vector  *nsM[_vector) 

The  nps_f liter _ data_flush  function  clears  the  filter  data 

ring  buffer.  The  protocol  for  nps_f liter _ data_flu8h  is: 

void  nps  filter  data  flush (Mps  filter  Info  *thls) 

The  l8_£llter  function  is  a  'C'  implementation  of  the  least 
squares  fit  GPS  state  vector  filter.  The  protocol  for  ls_£llter 
is: 

Int  l8_£llter (Stete_vector  *tan8_in, 

State_vector  *tans_out, 
double  tans_bu£[4] [60], 

Int  £bl,  int  point_num. 

Perturbations  *P) 

The  nps  filter  run  function  uses  data  stored  in  the 
filter  buffer  and  calls  l8_£ilter  to  process  this  data  and 
produce  a  smoothed  GPS  state  vector.  The  protocol  for 

nps_£ilter _ run  is: 

void  np8_£llter _ run(llps_£llter_ln£o  *thi8. 

State  vector  *out  vector.  Perturbations  *P) 
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G.  EDIT  fXmCTZQHS 


The  program  consists  of  several  edit  screens.  Each  screen 
is  conqposed  of  edit  fields  and  led>els.  An  edit  field  has  a 
screen  position  (x  and  y)  and  contains  a  converted  character 
string  representing  some  binary  varicdsle  value.  An  edit  led^el 
has  a  screen  position  and  contains  characters  to  be  printed  on 
the  screen. 

The  edit  screens  allow  the  user  to  manually  input  or  edit 
certain  data  for  various  functions.  The  data  being  edited  may 
be  data  that  is  currently  in  use  by  the  program.  It  may  even 
be  data  that  is  changing  such  as  a  state  vector.  The  program 
can  not  stop  to  wait  for  data  that  it  needs  for  processing  to 
be  updated  by  a  user.  For  this  reason,  real-time  editing 
screens  are  employed.  The  real-time  edit  screen  holds  the  data 
being  edited  in  a  temporary  variaUale  until  the  editing  is 
complete.  The  new  or  edited  data  is  reinserted  into  the 
original  variedsle  upon  leaving  the  current  edit  screen. 

Four  types  of  edit  fields  exist:  (1)  integer  edit  fields, 
(2)  double  edit  fields,  (3)  "yesno"  edit  fields  ("yes"  is  an 
integer  equal  to  one,  "no"  is  an  integer  equal  to  zero) ,  and 
(4)  day/hour/minute/second  (dhms)  edit  fields. 

For  each  type  of  edit  field  there  are  three  edit  field 
call  back  functions,  "get",  "put"  and  "key".  The  "get" 
function  converts  its  data  into  a  string.  The  "put"  function 
converts  the  string  back  to  the  appropriate  data  type.  The 
"key"  function  behaves  like  a  mini  key  hcuidler  for  the  data 


57 


field  in  use,  allowing  keyboard  entry  of  the  new  data  string. 
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VII.  SOFTNARB  OPERATION 


Like  any  progreun,  the  NPS  software  accepts  input,  operates 
on  that  input,  and  produces  output.  These  processes  are  the 
subjects  of  this  chapter. 


A.  PROGRAM  INPUT 

The  NPS  software  uses  data  'packets'  containing  state 
vectors  and  a  quaternion  as  input.  These  inputs  are  used  to 
produce  the  various  plots  for  graphical  display  of  the 
information. 

The  state  vector  describes  the  motion  of  an  orbiting  body 
in  a  rectangular  coordinate  system.  It  consists  of  a  position 
vector  and  a  velocity  vector  each  containing  x,  y,  and  z 
components,  and  a  time.  All  state  vector  comparisons  contained 
in  the  NPS  software  are  performed  in  M-50  (Aries-mean-of - 1950 
Cartesian  coordinate  system)  inertial  coordinates.  State 
vector  sources  used  in  the  NPS  software  include: 

•  Orbiter  INS  State  Vector  -  defines  the  shuttle  Orbiter 
state.  Initial  states  and  updates  are  provided  via  a 
ground  tracking  solution  or  the  orbiters  star  trackers. 
The  states  are  propagated  in  the  orbiter  computer  by  the 
' Super - G '  propagator . 

•  Target  INS  State  Vector  -  defines  the  state  of  the 
ORPHEUS/SPAS  or  other  satellite  that  the  Orbiter  is 
conducting  proximity  operations  with.  Initial  state  is 
provided  by  ground  tracking. 

•  Orbiter  GPS  State  Vector  -  defines  the  Orbiter  state  as 
described  by  the  onboard  TANS  GPS  unit. 
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•  SPAS  GPS  State  Vector  -  defines  the  ORFEUS/SPAS  satellite 
state  vector  as  described  by  the  German  GPS  unit  contained 
onboard  the  ORFEUS/SPAS. 

The  Orbiter  state  vector  operates  in  one  of  two  modes,  e. 
inertial  navigation  mode  and  a  relative  navigation  mode.  In 
the  inertial  navigation  mode,  the  Orbiter  state  is  updated  via 
ground  tracking.  This  mode  provides  a  state  vector 
representing  the  state  of  the  Orbiter  in  inertial  space.  In 
the  relative  navigation  mode,  a  target  state  vector  is  up- 
1 inked  to  the  Orbiter.  The  target  state  vector  is  considered 
to  be  a  'truth'  vector.  The  Orbiter' s  star  tracker  is  trained 
on  the  target  to  smooth  the  Orbiter  state  vector  relative  to 
the  target.  At  closer  ranges  (<30  miles)  this  relative  state 
vector  can  be  further  smoothed  using  sensor  data  from  the 
Orbiter' s  KU-band  radar  to  get  an  accurate  real-time  relative 
tracking  solution. 

The  quaternion  relates  the  Orbiter  body  coordinate  system 
to  the  M-50  inertial  coordinate  system.  It  is  calculated  from 
angular  rates  determined  by  the  inertial  measurement  unit 
(IMU)  and  updated  by  the  Orbiter' s  star  tracker.  The 
quaternion  is  required  by  the  NPS  software  for  computing 
attitude  related  information  such  as  pointing  information  to 
the  target. 

B.  DATA  OPERATIONS 

The  NPS  software  receives  M-50  inertial  state  vectors  from 
various  sources  and  processes  these  to  provide  relative  motion 
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and  vector  difference  plots.  To  accomplish  this,  the  incoming 
state  vectors  must  be  propagated  to  the  same  point  in  time, 
then  transformed  into  the  appropriate  form  for  display.  The 
following  is  a  simplified  explanation  of  how  the  code  works  by 
way  of  an  excimple. 

A  valid  Orbiter  INS  state  vector  is  received  by  NPS  with 
a  time  tag  of  0:00:00.  At  time  0:00:04,  four  seconds  later,  a 
valid  Orbiter  GPS  state  vector  is  received.  The  NPS  software 
recognizes  that  it  has  two  different  state  vectors  and  that  it 
would  like  to  compare  them.  The  time  stamp  of  the  older  state 
vector  is  compared  to  the  time  stamp  of  the  newer  state  vector 
and  the  time  difference.  At,  is  computed  (four  seconds  in  this 
case.)  The  older  state  vector  and  the  At  are  arguments  passed 
to  the  propagator. 

The  propagator  is  responsible  for  matching  the  time  stamps 
of  two  state  vectors.  In  the  propagator,  the  passed  M-50 
inertial  state  vector  is  transformed  into  Earth  Centered  Earth 
Fixed  (ECEF)  coordinates.  In  these  coordinates,  the  Earth 
gravity  model  and  atmospheric  model  are  applied  to  determine 
the  geopotential  forcing  function  and  drag.  The  resulting 
forcing  function  is  integrated  over  time  At  using  the  Runge- 
Kutta  integrator.  The  propagated  ECEF  state  vector  is 
transformed  back  into  M-50  inertial  coordinates  and  returned 
to  the  NPS  main  routine.  The  two  state  vectors  are  now  matched 
in  time  and  comparison  of  position  and  velocity  is  performed. 
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C.  PROGRAM  OOTPTJT 

The  NPS  software  presents  state  vector  conparisons  in 
three  different  forms:  (l)  the  R-bar/V-bar  plot,  (2)  the  state 
vector  difference  or  'Sawtooth'  plot,  and  (3)  the  Pitch/ Yaw 
display. 

1.  R-bar/V*bar  Plots 

The  R-bar/V-bar  plot  displays  the  relative  motion 
between  a  target  and  a  chaser  vehicle  and  is  of  particular 
importance  during  rendezvous  and  proximity  operations.  The 
relative  motion  plot  uses  a  target -centered  coordinate  system 


Figure  7-1.  Saaqple  R-bar/V-bar  plot. 
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which  the  Z-axis  rotates  with  the  target  and  is  positive 
airected  radially  toward  the  Earth,  the  X-eocis  is  curvilinear 
and  positive  in  the  direction  of  orbit  motion,  auad  the  Y-axis 
is  out -of -plane  and  completes  the  right-hand  coordinate 
system. 

R-bar/V-bar  plots  are  available  for  the  following 
target/chaser  combinations  of  state  vectors; 

•  SPAS  GPS/Orbiter  GPS 

•  SPAS  GPS/Orbiter  INS 

•  Orbiter  GPS/Orbiter  INS 

•  SPAS  GPS/Orbiter  target 

•  Orbiter  target/Orbiter  GPS 

•  Orbiter  target/Orbiter  INS 

Figure  7-1  is  an  example  of  an  R-bar/V-bar  plot. 

Orbiter  GPS/Orbiter  INS  and  SPAS  GPS/Orbiter  target 
plots  are  not  used  as  relative  motion  plots.  They  are  used  as 
another  method  of  viewing  the  difference  vector  and  show  on 
the  R-bar/V-bar  display  where  the  inertial  navigation  system 
thinks  the  Orbiter  or  SPAS  is  located  relative  to  where  GPS 
believes  it  to  be. 

2 .  Sawtooth  Plots 

The  relative  difference  or  'Sawtooth'  plots  display 
the  difference  in  the  magnitudes  of  the  position  or  velocity 
vectors  of  two  source  state  vectors.  This  is  the  tool  used  to 
quantify  the  error  between  the  inertial  navigation  system  and 
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GPS.  The  term  'Sawtooth'  was  derived  frcrni  the  expected  output 
display  of  the  plot.  It  is  Icnotm  that  the  inertial  system  will 
drift  over  time.  Assiiming  the  GPS  state  vector  error  to  be 
small  and  the  GPS  position  to  be  close  to  the  true  value,  it 
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Figure  7-2.  Sas^le  'Sawtooth'  plot. 


was  expected  that  the  difference  vector  magnitude  would  grow 
over  time.  On  each  occasion  of  an  INS  update  from  ground 
tracking  or  onboard  star  trackers,  it  was  expected  that  the 
difference  vector  would  be  reduced  to  a  small  value  as  the  INS 
position  and  velocity  were  returned  to  values  inside  the  GPS 
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error.  The  results  from  these  plots  serve  to  validate  or 
invalidate  the  use  of  GPS  for  Orbiter  state  vector  updating. 
Two  state  vector  source  combinations  for  'Sawtooth'  plots  are 
available : 

•  Orbiter  GPS/Orbiter  INS 

•  SPAS  GPS/Orbiter  target 

Figure  7-2  is  an  excimple  of  a  'Sawtooth'  plot. 

3.  Pitch/Yaw  Displays 

The  Pitch/Yaw  display  gives  a  graphical  presentation 
of  the  Orbiter  (TOP  and  SIDE  views)  and  a  target  pointing 
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vector  measured  in  pitch  up  from  Orbiter  body  X-eucis  and  yaw 
about  the  rotated  Orbiter  body  Z-axis.  These  angles  are 
computed  from  the  state  vectors  of  the  Orbiter  and  target,  and 
the  Orbiter  quaternion.  Target  distance  is  also  shown.  Three 
Target/chaser  state  vector  source  combinations  for  the 
Pitch/Yaw  plot  can  be  selected: 

•  SPAS  GPS/Orbiter  GPS 

•  Orbiter  target/Orbiter  INS 

•  SPAS  GPS/Orbiter  INS 

Figure  7-3  is  an  example  of  a  Pitch/Yaw  plot. 
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VZII.  DATA  COLLBCTZQV  AMD  AMALTSZS 


During  Discovery's  ten  day  mission,  hardware  equivalent  to 
the  flight  hardware  was  assembled  in  Mission  Control  at  the 
Johnson  Space  Center  (Figure  8.1)  .  The  128  Kbyte  downlink  data 
streeun  was  wired  into  a  desktop  computer  and  a  GRID  1535 
laptop  computer,  each  loaded  with  the  "PCDecom"  software.  The 
desktop  "PCDecom"  unit  was  used  to  record  the  downlink 
telemetry  for  the  entire  flight  on  digital  magnetic  tape.  This 
data  was  used  for  playback  and  post- flight  analysis.  The 
laptop  "PCDecom"  unit  was  connected  via  an  RS-232  port  to 
another  generic  laptop  computer  loaded  with  the  NPS  software 
(stand-alone  flight  version)  .  This  allowed  ground  personnel  to 
view  the  program  in  realtime  exactly  as  the  flight  crew  saw 
it.  All  state  vector  information  for  the  Orbiter  inertial 
system  and  the  ORFEUS/SPAS  were  available  for  plotting.  The 
TANS  GPS  data  was  not  availeJsle  for  viewing  from  Mission 


Control  during  the  flight. 

Post -flight  data  analysis 
included  preparation  of  the 
data  for  replay  and  merging 
of  the  PCMMU  recorded  data 
and  the  TANS  GPS  data  stored 
separately  in  flight. 
Subsequent  sections  of  this 
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chapter  summarize  the  flight  data  collected  and  analyzed  at 
the  time  of  this  writing  with  respect  to  the  objectives  of  the 
DTO  stated  in  Chapters  I  and  II. 

A.  GPS  STATE  VECTOR  AHALYSIS 

The  level  II  DTO  objective,  conparison  of  GPS  state  vector 
data  with  corresponding  inertial  or  ground  tracking  state 
vector  solutions,  was  met  yielding  very  useful  results. 
Comparisons  of  both  Orbiter  INS  vs  TANS  GPS  and  Orbiter  target 
vs  SPAS  GPS  were  obtained. 


Figure  8.2  Orbiter  INS  vs  TANS  GPS  "Sawtooth*  plot 
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1.  Orblt«r  INS  va  TANS  OPS 


A  comparison  of  the  inertial  solution  for  the  Orbiter 
state  and  the  TANS  GPS  solution  was  performed  during  flight 
when  the  Orbiter  attitude  was  permitted  four  satellite  GPS 
reception.  While  continuous  GPS  state  vector  information  was 
not  available  throughout  the  flight,  there  were  several 
periods  of  continuous  reception  exceeding  several  hours  in 
duration.  This  allowed  observation  of  the  expected  'sawtooth' 
predicted  in  the  Orbiter  INS  vs  TANS  GPS  difference  plot. 

Figure  8.2  shows  the  state  vector  differences  for  GPS 
input  states  vs  inertial  states  during  the  longest  continuous 
period  of  GPS  state  vector  reception  during  the  mission.  Over 
the  eight  hour  period  shown,  the  difference  in  the  INS  and  GPS 
position  is  observed  to  grow  to  approximately  35,000  feet 
before  a  navigational  update  from  the  ground  removes  inertial 
system  drift  error  and  reduces  the  error  to  approximately  1000 
feet.  GPS  state  vector  reception  is  lost  shortly  after  the 
update . 

Figure  8.2  shows  the  first  step  in  validating  the  use 
of  GPS  for  on  orbit  navigation.  While  the  inertial  system 
position  accrues  a  significant  error  over  time,  the  GPS 
position  error  remains  bounded  by  the  limits  of  the  GPS 
receiver  and  the  dithering  of  the  incoming  GPS  signal  caused 
by  selected  availcUaility  (SA)  . 

It  is  important  to  note  that  the  data  shown  in  Figure 
8 . 2  includes  only  comparison  of  the  incoming  GPS  state 
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vectors,  not  the  propagated  GPS  state.  Propagation  of  the  GPS 
state  vector  yields  a  position  difference  plot  with  erratic 
spikes  between  updated  states  due  to  errors  in  GPS  velocity  on 
the  order  of  one  meter  per  second.  Such  errors  are  probably 
due  to  the  high  Position  Dilution  of  Precision  (PDOP)-  of  the 
GPS  signal  observed  during  flight  and  concur  with  expected 
errors  for  the  observed  PDOP.  [Ref.  7] 

2.  Orblter  Target  vs  SPAS  GPS 

Comparisons  of  Orbiter  target  and  SPAS  GPS  state 
vectors  were  also  made  through  clever  manipulation  of  the  post 
flight  data.  During  flight  the  target  state  vector  was  updated 
only  periodically  when  necessary  to  perform  certain  tasks  such 
as  rendezvous  commencement.  During  the  rendezvous  itself,  it 
was  not  necessary  to  continually  update  the  target  state 
vector  because,  once  the  rendezvous  commenced,  the  target 
state  was  assumed  to  be  a  truth  state  and  the  Orbiter  state 
was  computed  relative  to  the  target.  Following  the  rendezvous 
and  capture  of  the  SPAS,  the  SPAS  GPS  data  could  be  compared 
to  the  Orbiter  inertial  system  since  the  Orbiter  state  and  the 
target  state  coincided. 

Figures  8.3  and  8.4  show  a  comparison  of  position  and 
velocity  between  SPAS  GPS  and  the  coincident  Orbiter 
INS/target  states  for  a  Scimple  time  period  following  capture 
of  the  SPAS.  These  plots  show  both  the  incoming  state  and  its 
NPS  propagated  value.  State  vector  updates  can  be  identified 
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Figure  8.4  Repressntatlve  data  of  comparison  of  SPAS  GPS  and 
Orblter  target  state  vector  velocity. 
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by  the  beginning  of  the  discontinuities  shown.  These  plots 
illustrate  the  danger  of  propagating  an  orbit  with  a  bad  state 
vector  velocity.  Position  errors  accumulate  rapidly.  The 
updated  position  fixes,  however,  are  quite  consistent  with 
position  errors  around  1000  feet. 

B.  GPS  RELATIVE  NAVIGATION 

The  level  III  DTO  objective  of  plotting  the  rendezvous 
profile  with  relative  GPS  was  a  partial  success.  Relative  GPS 
navigation  was  not  possible  during  the  rendezvous  due  to  the 
lack  of  TANS  GPS  state  vectors  during  this  period.  The  four 
satellite  reception  required  for  three  dimensional  GPS 
position  determination  was  not  achieved  by  the  onboard  TANS 
GPS  unit  during  the  rendezvous  event.  However,  SPAS  GPS 
reception  was  good  during  this  period  and  relative  positioning 
of  the  SPAS  GPS  with  respect  to  the  Orbiter  inertial  state 
vector  was  possible.  The  relative  motion  plots  produced  were 
similar  in  appearance  to  the  relative  motion  plots  produced 
using  inertial  state  vector  sources  but  lacked  the  accuracy 
and  relative  smoothing  required  for  use  during  rendezvous 
operations . 

C.  RELATIVE  MOTION  PLOTTING  RENDEZVOUS  AID 

The  level  IV  DTO  objectives  provided  the  most  exciting 
results  of  the  project  as  the  program  demonstrated  itself  to 
be  a  powerful  and  useful  tool  during  the  rendezvous  with  the 
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ORFEUS/SPAS  providing  operationally  useful  information  to  the 
flight  crew  in  realtime. 


Figure  8.5  SPAS  Rendezvous.  TZ  Bum  (Initial  look) 


Figure  8.5  shows  the  rendezvous  profile  up  to  one  and  one 
half  revolution  prior  o  intercept  with  the  pre/post -TI  burn 
predictors  displayed.  Using  the  uplinked  TI  burn  rates  given 
by  mission  control,  the  crew  was  able  to  view  the  predicted 
results  of  the  upcoming  maneuver. 

As  the  Orbiter  closed  the  distance  to  the  SPAS,  the 
relative  state  vector  solution  is  'sweetened'  by  the 
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rendezvous  radar.  As  figure  8.6  illustrates,  the  NPS  software 
predicted  the  fact  that  the  planned  TI  bum  might  cause  the 
Orbiter  to  fall  short  of  the  targeted  intercept  unless  larger 
than  planned  MC  burns  were  performed  following  TI.  The  actual 
TI  burn  did,  in  fact,  target  the  Orbiter  short  and  the  crew 
was  well  prepared  when  the  larger  MC  burns  required  for 
rendezvous  were  calculated. 
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Figure  8,6  SPAS  Rendezvous  TI  Bum.  Predictor  falls  short 

of  target. 


Given  a  similar  situation  in  the  future,  using  a  certified 
code  with  the  NPS  features,  an  operator  could  conceivcd)ly  use 
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the  Predictor/ Future  Thrust  option  of  the  software  to  'walk' 
the  post-TI  predicted  trajectory  to  the  desired  intercept 
point  and  suggest  modifications  to  burns  as  appropriate.  The 
value  of  this  tool  is  even  more  evident  in  a  situation  where 
realtime  communications  with  mission  control  is  impractical, 
such  as  a  manned  mission  to  Mars,  or  when  communications  are 
not  possible  due  to  communications  loss  such  as  that  occuring 
during  the  TDRSS  gap. 

Figure  8.7  shows  the  final  minutes  of  the  rendezvous.  The 
serpentine  trajectory  recorded  is  the  result  of  several 
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Figure  8.7  SPAS  Rendezvous.  Final  Approach. 
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braking  and  elevating  (negative  R-bar)  maneuvers  used  to 
achieve  V-bar  crossing  400  feet  ahead  of  the  target.  Review  of 
the  cockpit  video  tape  taken  during  the  rendezvous  and  debrief 
discussions  with  Discovery  pilot  Bill  Readdy  revealed  that  the 
NFS  software  confirmed  information  from  'approved'  flight  aids 
as  well  as  providing  that  information  faster  and  more  reliably 
than  previous  programs  used  for  rendezvous  operations. 
Significantly,  the  inertial  system  was  able  to  sense  the 
firing  of  maneuvering  thrusters  allowing  the  NFS  software 
predictors  to  provide  instantaneous  feedback  of  a  maneuver's 
effectiveness  to  the  crew.  As  a  result  of  the  improved 
situational  awareness  provided  by  the  NFS  software  and  other 
rendezvous  software  flown  on  STS-51,  Discovery's  mission 
commander,  Frank  Culbertson,  skillfully  executed  the  most  fuel 
efficient  rendezvous  to  date  in  the  space  shuttle  program. 
[Ref.  8]  In  fact,  data  provided  in  [Ref.  9]  confirmed  that  the 
actual  fuel  consumed  during  the  manual  flight  phase  of 
Discovery's  rendezvous  was  about  66  percent  of  budgeted  fuel 
usage  for  the  same  period. 
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IX.  LBSSONS  LBABMBD 

Vfhile  the  Development  Test  Objective  was  an  unqualified 
success,  as  with  any  project,  there  were  many  lessons  learned 
and  areas  for  improvement  found.  The  following  is  a  summary  of 
items  noted  for  both  improvements  to  the  software  and  to  the 
manner  in  which  it  is  employed. 

A.  '6160'  (6ARBA6E  IN,  6ARBA6B  OUT):  OPS  VELOCITY  ACCURACY 

The  NPS  relative  motion  plots  are  only  as  good  as  the 
state  vectors  provided  to  the  program.  This  introduces  the 
problem  of  poor  accuracy  of  velocity  derived  from  GPS  data. 
Assiame  that  the  GPS  position  information  is  good.  If  the 
velocity  error  is  significant,  then  any  propagation  of  the 
state  vector  will  integrate  that  error  over  the  time  of 
propagation.  Unfortunately,  GPS  derived  velocity  errors  are  on 
the  order  of  a  meter  per  second.  This  is  a  significant  error 
in  terms  of  orbital  motion.  Propagation  of  state  vectors  with 
velocity  errors  of  this  magnitude  leads  to  significant 
position  errors  in  short  time  spans. 

Solutions  to  this  problem  may  include  incorporation  of  a 
Precise  Position  Service  (Military)  GPS  receiver  to  reduce  the 
errors  caused  by  selected  availability,  the  use  of  recursive 
Kalman  filtering  of  the  GPS  state  vector  to  smooth  the 
velocity  solution,  or  a  combination  of  both.  The  use  of  the 
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least  squares  fit  GPS  filter  currently  used  by  the  progreun  is 
an  Inadequate  solution  due  to  the  time  it  requires  to  produce 
a  smoothed  state  vector. 

B.  MORE  'GIGO'  OR  'NINO'  (NOTHING  IN,  NOTHING  OUT) 

Related  to  the  GIGO  problem  noted  above  is  the  problem  of 
discontinuous  data.  Again,  the  program  output  is  only  as  good 
as  its  input.  Of  course,  if  no  target  state  vector  is 
available,  then  relative  motion  plotting  is  impossible.  Such 
was  the  case  for  significant  portions  of  the  flight. 

The  target  state  vector  was  not  maintained  by  ground 
tracking  except  (and  fortunately)  during  separation, 
rendezvous,  and  proximity  operations  with  the  ORFEUS/SPAS.  The 
SPAS  GPS  state  vector  was  only  available  during  limited  time 
periods  during  the  flight  due  to  the  high  volume  of  telemetry 
from  the  ORFEUS/SPAS' s  onboard  experiments.  Segments  of  the 
flight  when  neither  the  target  state  vector  nor  the  SPAS  GPS 
state  vector  were  available  severely  reduced  the  capabilities 
of  the  relative  motion  plotting  functions.  Relative  motion 
plotting  is  still  available  if  the  target  state  vector  is 
known  and  hand  keyed  into  the  program.  However,  this 
information  is  still  dependent  on  the  ground  providing  good 
target  state  vector  information  to  the  crew.  The  lack  of  a 
good  target  vector  during  periods  of  SPAS  GPS  reception  also 
hampered  comparison  of  these  two  state  vector  sources. 
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The  TANS  GPS  data  is  not  continuous  as  the  GPS  reception 
was  dependent  upon  the  Orbiter's  flight  attitude.  In  addition, 
while  good  TANS  GPS  reception  was  the  rule  during  the  flight, 
the  four  satellite  coverage  required  for  three  dimensional 
position  and  velocity  determination  was  the  exception.  As  a 
result,  the  actual  percentage  of  flight  time  with  good  TANS 
GPS  state  vectors  was  small.  Possible  solutions  for  this 
include  the  use  of  exterior  mounted  GPS  antennae  in  future 
flights  to  increase  the  range  of  good  Orbiter  attitudes  for 
reception. 

C.  THE  GPS  FILTER 

The  GPS  filter  written  by  McDonnell  Douglas  for  the 
software,  while  functional,  was  inadequate  for  the  required 
task.  This  filter  requires  high  fidelity  propagation  of  the 
latest  seven  GPS  state  vectors  back  through  the  last  sixty 
collected  GPS  state  vectors  (420  high  fidelity  propagations) , 
and  comparison  of  the  outcomes  with  the  recorded  state  vectors 
in  order  to  solve  for  one  'smoothed'  state  vector.  This 
'batch'  process  takes  on  the  order  of  one  minute  of  CPU  time 
on  the  computers  currently  in  use.  This  dedication  of  CPU  time 
to  a  single  task  was  not  an  affordable  luxury  for  the  mission. 
The  need  for  continual  GPS  data  reception,  processing,  and 
storage  to  disk,  as  well  as  plotting  functions  of  the  NPS  code 
precluded  use  of  the  filter. 
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A  recommended  replacement  for  the  least  squares  fit  GPS 
filter  might  be  a  recursive  filter  that  stores  a  solution  and 
updates  that  solution  progressively  rather  than  performing  a 
'batch'  operation  upon  selection. 

D.  TDRSS  COMKOMICXTIONS  OAFS 

Once  every  revolution  the  Orbiter  experiences  a  total  loss 
of  communications  with  the  ground  due  to  the  gap  in  TDRSS 
coverage  over  the  Indian  Ocean.  This  loss  of  signal,  or  LOS, 
lasts  between  seven  to  eight  minutes  and  includes  a  loss  of 
the  down- link  telemetry  stream  which  is  stored  on  digital 
magnetic  tape  for  post- flight  analysis.  The  crew  does  not 
experience  this  loss  of  data  in  flight.  In  fact,  the  telemetry 
is  stored  onboard  and  down- linked  after  communications  are 
restored.  The  data  can  then  be  recovered  and  integrated  with 
the  recorded  data.  This  process  requires  additional  data  link 
hardware,  some  clever  programming,  and  considerable 
coordination  with  NASA.  An  alternative  approach  might  be  to 
store  the  NPS  data  packets  on  board  on  the  laptop  hard  disk 
during  LOS  in  the  same  manner  that  the  TANS  GPS  data  was 
stored  throughout  the  flight.  Integration  of  the  'gapped' 
data  collected  on  the  ground  and  the  NPS  data  packets  stored 
on  board  during  LOS  could  be  accomplished  by  much  simpler 
means  than  the  process  required  to  recover  the  LOS  data  from 
NASA. 

0 
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B.  A  POST-PLIOBT  DBBRZBP/TBAZVIHQ  TOOL 

The  NFS  software  has  a  significant  value  as  a  post -flight 
debriefing  tool.  Once  the  flight  data  is  replayed  from  the 
digital  tape  and  the  NFS  packets  are  stored  to  disk, 
rendezvous  and  proximity  operations  from  the  flight  can  be 
reviewed  by  the  flight  crew  and  by  crew  members  preparing  for 
future  missions  on  the  'replay'  version  of  the  program.  The 
simulator  version  of  the  NFS  software  can  also  be  used  for 
crews  to  practice  their  own  maneuvers  or  demonstrate 
hypothetical  scenarios.  Either  replay  or  simulation  require 
only  a  desktop  or  laptop  computer.  While  not  a  substitute  for 
current  trainers  and  simulators,  this  capability  is  an 
invaluable  supplement  to  both  flight  crews  and  to  support 
personnel  who  otherwise  might  not  receive  expensive  simulator 
time. 

F.  GROUMD  CONTROLLERS  AID 

In  a  similar  fashion  to  that  described  above,  the  NFS 
software  is  also  a  valuable  situational  tool  to  mission 
control/payload  support  personnel,  providing  a  real-time 
picture  of  the  rendezvous  when  video  down- link  is  not 
availcUale.  (Use  of  the  KU-band  radar  during  rendezvous 
precludes  the  down-link  of  video  due  to  limited  bandwidth.)  It 
is  possible  for  ground  personnel  to  plug  into  the  data  link  at 
mission  control  regardless  of  whether  or  not  the  Orbiter  is 
equipped  with  the  appropriate  hardware  and  software.  This  was 
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the  case  in  December  1993  when  crew  members  of  STS *60, 
practicing  for  the  Wake  Shield  Facility  experiment  in  1994, 
and  Hubble  Space  Telescope  representatives  used  the  NFS 
software  at  mission  control  during  the  Hubble  Space  Telescope 
rendezvous . 
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X.  CQNCLUSIQIIS 


The  NPS  software  positively  contributed  to  the  outcome  of 
the  STS- 51  mission  and  continues  to  be  a  springboard  for 
research  and  experimentation  in  the  use  of  real-time  data  for 
situational  awareness  to  assist  the  flight  crew  on  orbit.  The 
best  subjective  review  of  the  software  comes  from  the  flight 
crew  of  STS -51.  Their  inputs  concerning  the  project  are 
recorded  in  the  STS-51  FLIGHT  CREW  REPORT  [Ref.  10]  and 
appropriate  remarks  follow. 

For  reference,  the  certified  rendezvous  software  used  by 
NASA  is  "Payload  Bay"  (PLBAY)  .  PLBAY  is  not  automated, 
requiring  the  operator  to  manually  input  most  parameters.  The 
progrcim  does  not  offer  many  of  the  options  availaible  in  the 
NPS  software.  It  also  does  not  offer  the  flexibility  for 
growth  that  the  NPS  software  contains.  The  "Rendezvous/Prox 
Ops  Program"  (RPOP) ,  is  an  automated  version  of  PLBAY, 
offering  reduced  need  for  user  interface,  but  no  new 
functionality  over  PLBAY.  These  programs  are  referred  to  in 
the  remarks  regarding  the  NPS  software. 

A.  Flight  Crew  Remarks 

The  most  convincing  argument  for  continued  use  of  programs 
like  NPS  on  future  missions  comes  directly  from  feedback 
provided  by  the  flight  crew.  Mission  Specialist  Dr.  James 
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Newman  comments  on  the  use  of  the  NPS  software  in  the  STS-51 
FLIGHT  CREW  REPORT.  Referring  to  the 
nps_rvplot _ dl8play_future  and  nps_predlctor _ thrust 

functions,  he  writes; 

.  .  .These  programs  (PLBAY,  RPOP,  and  NPS)  ran  from  well 
prior  to  TI  through  the  entire  rndz  and  prox  ops.  The  NPS 
code  was  able  to  perform  future  burns  as  well  as  "what  if" 
thruster  firings  and  predicted  that  the  TI  burn  would 
result  in  a  short  rndz  case.  This  was  born  out  and  MCI 
through  4  all  worked  to  correct  this. 

Dr.  Newman  compared  the  outputs  and  functionality  of  the  NPS 

software  to  PLBAY  and  RPOP,  stating; 

. . .RPOP  and  the  NPS  plots  were  evaluated  against  the 
certified  version  of  PLBAY  and  contributed  to  the  overall 
situational  awareness.  The  NPS  code  had  a  number  of 
features  desirable  in  operational  versions  of  RPOP, 
including  the  ability  to  select  predictors  more  than  9 
minutes  in  the  future.  It  was  also  able  to  maintain  the 
no- thrust  predicted  trajectory  and  the  "what -if" 
trajectory  at  the  same  time,  making  comparisons  of  desired 
thrust  inputs  easier  to  do.  And  NPS  kept  track  of  the 
number  of  "what- if"  firings  in  the  various  directions  and 
the  net  delta- v  in  the  orbiter  axes. 

Dr.  Newman's  recommendations  to  NASA  were  clearly  stated; 

Incorporate  desirable  features  from  the  NPS  code  into  RPOP 
to  improve  situational  awareness  during  the  rendezvous  and 
proximity  operations. 

Concerning  the  GPS  on-orbit  demonstration.  Dr.  Newman 
reported; 

.  .  .The  NPS  software  produced  a  delta  plot  of  the  GPS 
position  and  on-board  position.  The  first  time  this  was 
observed,  the  delta  was  ~18kft.  A  short  while  later  it  was 
observed  to  be  about  300  ft!  This  was  just  before  and 
after  MCC  unlinked  a  new  orbiter  state  vector  and  showed 
dramatically  that  the  GPS  was  working  as  expected. 
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Post-flight  analysis  of  the  GPS  data,  Orbiter  onboard 
position,  and  reference  trajectory  have  since  confirmed  the 
real-time  data  observed  in  flight.  [Ref.  11] 

B.  Future  NFS  Software  DevelopoMnt 

The  NPS  software  is  not  fixed.  It  is  a  continually 
evolving  experiment  with  the  goals  of  ::ontinued  improvement  in 
providing  the  flight  crew  with  added  situational  awareness. 
Since  the  return  of  STS -51,  the  software  has  been  modified  to 
incorporate  features  suggested  by  astronauts  and  mission 
planners.  New  features  include  the  ability  to  view  the 
relative  motion  plot  from  side,  top,  and  end  on  views,  display 
of  closure  rates,  orbital  plane  crossing  rate  (Y-dot)  and  the 
plane  crossing  time,  and  improvements  to  display  options  such 
as  scaling. 

A  modified  version  known  as  "NPS  lite",  processing  only 
the  Orbiter  and  target  state  vectors,  and  displaying  Orbiter 
pitch,  roll,  and  yaw  angles  (to  observe  Orbiter  dynamics)  ,  was 
prepared  for  use  by  STS -60  in  1994  for  providing  display  of 
the  rendezvous  and  proximity  operations  of  Discovery  with  the 
Wake  Shield  Facility  experiment. 

Currently,  STS- 66,  scheduled  to  fly  late  in  1994,  is 
evaluating  the  use  of  NPS  for  another  GPS  relative  navigation 
test.  On  this  flight  the  GPS  equipped  SPAS  will  again  be 
deployed  and  retrieved.  The  TANS  GPS  receiver  will  be  located 
in  the  payload  bay  to  improve  GPS  signal  reception. 
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still  ether  flight  opportunities  exist  if  the  NPS  software 
continues  to  offer  useful  features  not  currently  availeUale  in 
'approved'  software.  Some  of  these  desireible  features  include 
the  incorporation  of  the  payload  bay  laser  data  (this  system 
is  being  brought  on  line  for  use  in  MIR  and  Space  Station 
rendezvous)  ,  raw  radar  data  solutions,  and  a  'Windows'  version 
of  the  program. 

The  NPS  software  serves  as  a  working,  "proven"  test  and 
evaluation  prograim  for  new  uses  of  real-time  data  available 
via  "PCDecom".  This  includes  evaluation  of  new  algorithms  for 
rendezvous  and  relative  motion  display,  comparison  of  future 
test  navigational  sources,  and  visual  display  of  non- 
navigational  data  such  as  the  shuttle's  remote  arm  position. 
The  opportunities  for  future  research  and  development  are 
unlimited.  It  is  the  hope  of  the  ’thor  that  others  will 
continue  to  use  and  develop  the  NPS  software,  offering 
improvements  that  will  make  it  a  still  more  valuable  product 
in  our  nation's  space  progrcim. 
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APPENDIX  A 


DKFZHXTZQNS 

Body  Axis  Coordinate  System 

A  Cartesian  right-handed  coordinate  system  with  origin  at 
the  Orbiter  center  of  mass.  The  X-aocis  is  parallel  to  the 
Orbiter  structural  body  X-aocis,  positive  towards  the  nose. 
The  Z-axis  is  parallel  to  the  Orbiter  plane  of  symmetry, 
positive  down  with  respect  to  the  Orbiter  fuselage.  The  Y- 
axis  completes  the  right-handed  system. (Ref  2:  p.  A-2) 


Earth -centered.  Earth- fixed  (ECEF)  Coordinate  System 

A  Cartesian  coordinate  system.  The  center  is  at  the  Earth's 
center.  The  X-axis  points  toward  the  Greenwich  meridian  at 
the  equator,  the  Z-aixis  points  toward  the  North  Pole,  and 
the  Y-aucis  completes  the  right-handed  coordinate  system. 
The  coordinate  system  rotates  with  Earth. 


Local -vertical,  Circular  (LVC)  Coordinate  System 

The  LVC  coordinate  system  is  a  target -centered  coordinate 
system.  The  Z-axis  rotates  with  the  target  and  is  positive 
directed  radially  toward  the  Earth.  The  X-axis  is 
curvilinear  and  positive  in  the  general  direction  of  orbit 
motion.  The  Y-aucis  is  normal  to  the  target's  orbital  plane 
and  completes  the  right-hand  coordinate  system. 


Local -vertical.  Local -horizontal  (LVLH)  Coordinate  System 

The  LVLH  coordinate  system  is  a  target -centered  coordinate 
system.  The  Z-axis  rotates  with  the  target  and  is  positive 
directed  radially  toward  the  Earth.  The  X-axis  is  positive 
in  the  general  direction  of  orbit  motion.  The  Y-axis  is 
normal  to  the  target's  orbital  plane  and  completes  the 
right-hand  coordinate  system. 


Midcourse  Correction  (MC)  Maneuver 

Rendezvous  maneuver  performed  as  necessary  to  ensure  a 
correct  intercept  from  Terminal  Initiation  (TI)  to  the 
target. (Ref  2;  p.  3-8) 


M-50 

Aries -mean -of -1950  Cartesian  coordinate  system.  Inertial 
coordinate  system  with  the  origin  at  the  center  of  the 
Earth.  The  epoch  is  the  beginning  of  the  Bessel ian  year 
1950  or  Julian  ephemeris  date  2433282.423357.  The  X-axis 
points  toward  the  mean  vernal  equinox  of  epoch,  the  Z-axis 
points  toward  the  Earth's  mean  rotational  cocis  of  epoch  and 
is  positive  north,  and  the  Y-aucis  completes  the  right- 
handed  system. (Ref  2:  p.  A-l) 


Remote  Manipulator  System 

Mechanical  arm  on  the  payload  bay  longeron.  It  is 
controlled  from  the  Orbiter  aft  flight  dec)c  to  deploy, 
retrieve,  or  move  payloads. 


Orbiter 

Manned  orbital  flight  vehicle  of  the  Space  Shuttle  system. 


Orbiter  Star  Tracker 

The  Orbiter  star  tracker  (STRK)  is  an  image  dissector 
electro- optical  tracking  device  used  to  obtain  precise 
angular  measurements  of  selected  stars  and  sun  illuminated 
orbiting  objects  (targets) .  These  measurements  are  used  to 
determine  the  Orbiter' s  attitude  in  inertial  space,  and 
this  data  is  used  to  align  the  inertial  measurement  units 
(IMUs)  .  The  STRK  also  provides  angular  data  from  the 
Orbiter  to  a  target  being  tracked. (Ref  2:  p.  2-1) 


Posigrade  Burn 

A  posigrade  burn  is  one  which  increases  the  speed  but  does 
not  change  the  direction  of  the  spacecraft  at  the  point  it 
is  applied.  A  posigrade  burn  increases  the  energy,  semi- 
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major  axis,  and  period  of  the  orbit.  For  example,  if  the 
orbit  was  originally  circular,  a  posigrade  maneuver  will 
create  an  elliptical  orbit, with  the  thrust  point  becoming 
perigee  and  apogee  occurring  180  degrees  of  orbit  travel 
away. (Ref  2:  p.  1-11) 


Radial  Burn 

A  radial  burn  is  one  in  which  the  thrust  is  applied  in  a 
direction  perpendicular  to  the  spacecraft's  velocity  vector 
and  in  the  orbital  plane  of  the  spacecraft.  (Ref  2:  p.  1-18) 


Retrograde  Burn 

A  retrograde  burn  is  one  which  decreases  the  speed  but  does 
not  change  the  direction  of  the  spacecraft  at  the  thrust 
point.  A  retrograde  burn  decreases  the  energy,  semi -major 
axis,  and  period  of  the  orbit.  For  example,  if  the  orbit 
was  originally  circular,  a  retrograde  maneuver  will  create 
an  elliptical  orbit, with  the  thrust  point  becoming  apogee 
and  perigee  occurring  180  degrees  of  orbit  travel  away. (Ref 

2;  p.  1-11) 


RS-232 

Standard  serial  port  interface. 


RS-422 

Standard  serial  port  interface. 


Selected  Availability 

This  is  the  name  of  the  policy  and  implementation  scheme  by 
which  users  of  GPS  will  have  their  accuracy  limited  to  100 
meters  2dRMS  horizontal  and  156  meters  2dRMS  vertical.  (Ref 
1:  p.  D-3) 


Space  Shuttle 

Orbiter,  external  tanks,  and  solid  rocket  boosters. 
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state  Vector 


The  state  vector  defines  the  state  of  an  orbiting  body.  The 
state  vector  consists  of  a  position  vector,  a  velocity 
vector,  and  a  time. 


Terminal  Initiation  (TI) 

The  Terminal  Initiation  bum  is  designed  to  change  the 
rendezvous  approach  from  one  of  phasing  to  a  direct 
intercept.  The  burn  occurs  approximately  5  minutes  before 
orbital  noon  at  the  apogee  of  the  post  NCC  orbit. (Ref  2:  p. 
3-7) 


Quaternion 

A  four  parameter  representation  of  a  transformation  matrix. 
It  provides  a  numerical  relationship  between  coordinate 
frames.  Quaternions  are  used  due  to  their  convenient  small 
size;  that  is,  four  parameters,  as  opposed  to  nine 
parameters  in  a  transformation  matrix  (or  direction  cosine 
matrix) .  This  greatly  reduces  computer  computation  time 
when  numerous  coordinate  frames  are  involved  in  a 
transformation. (Ref  4:  p.  1-1) 


WGS-84 

World  Geodetic  System  (1984) ,  a  mathematical  reference 
ellipsoid  used  by  GPS,  having  a  semi-major  axis  of  6378.137 
km  and  a  flattening  of  1/298.257223563.  (Ref  3:  p.  D-4)  This 
model  is  used  for  orbit  perturbation  harmonic  prediction. 

WGS-84  is  also  used  to  refer  to  an  earth- centered,  earth- 
fixed  (ECEF)  coordinate  system. 
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ABBBSVZATIGMS 


CCTV 

COAS 

DTO 

ECEF 

GPS 

LVC 

LVLH 

IMU 

INS 

KU-BAND 

MCI 

NCI 

NCC 

NH 

ORFBUS 


PCMMU 

PGSC 

PRCS 

PROX  OPS 

R-bar  (R) 

SA 

SEP 

SPAS 

STRK 

STS 

TI 

V-bar  (V) 


Closed  Circuit  Television 
Crew  Optical  Alignment  Sight 

Development  Test  Objective 

Earth -centered,  earth- fixed  coordinate  system 

Global  Positioning  System 

Local  Vertical  Circular  Coordinate  System 
Local  Vertical/Local  Horizontal  Coordinate  System 

Inertial  Measurement  Unit 
Inertial  Navigation  System 

15.250  to  17.250  GHz 

Midcourse  Correction  Maneuver  1 

Nominal  Correction  1  (Phasing  Maneuver) 

Nominal  Corrective  Combination  (Maneuver) 

Nominal  Height  (Adjustment  Maneuver) 

Orbiting  Retrievable  Far  auid  Extreme  Ultraviolet 
Spectrometer 

Pulse  Code  Modulation  Master  Unit 
Portable  GRID  Systems  Con^uter 
Primary  Reaction  Control  System 
Proximity  operations  phase 

Radius  vector  eixis 

Selected  Availability 
Separation 

Shuttle  Pallet  Satellite  (German) 

Orbiter  Star  Tracker 
Shuttle  Transportation  System 

Terminal  Initiation 

Velocity  vector  eucis 
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APPENDIX  B 


NPS  SOPTNABB  USER  MANUAL 


A.  Organisation 

This  user  manual  is  divided  into  two  main  parts. 

a  Getting  Started  -  This  first  section  describes  how  to 
install  and  start  the  NPS  State  Vector  Comparison  and 
Relative  Motion  Plotting  prograun  (referred  to  as  the  NPS 
software) . 

a  Tutorial  -  The  Tutorial  is  an  introduction  to  the  NPS 
software.  The  basic  functions  are  described.  For  a 
detailed  reference  of  functions,  see  Chapters  V,  VI,  and 
VII  of  the  Naval  Postgraduate  School  thesis  NPS  State 
Vector  Analysis  and  Relative  Motion  Plotting  Sof  tware  for 
STS-51  by  Lt.  Lee  Barker,  USN,  and  Chapters  III,  IV,  and 
V  of  the  Naval  Postgraduate  School  thesis  Theoretical 
Basis  for  State  Vector  Comparison,  Relative  Position 
Display,  and  Relative  Position/Rendezvous  Prediction  by 
Lt.  Lester  Makepeace,  USN. 


B.  Getting  Started 

1.  NPS  Software  System  Requirements 

The  NPS  software  written  for  STS-51  DTO  700-6  was 
designed  to  run  on  the  GRID  1530  Portable  Grid  Systems 
Computer  (PGSC) .  The  GRID  1530  PGSC  contains  an  80386  10  MHz 
CPU  with  an  80387  coprocessor,  4  Mbytes  RAM,  200  Mbyte 
internal  hard  disk,  1.44  Mbyte  3.5"  floppy  drive,  and  RS- 
232/422  ports.  The  basic  NPS  software  requires; 

e  IBM  PC/XT  or  compatible  MS-DOS  computer,  10  MHz  80386  or 
faster  recommended. 

m  MS-DOS  Version  3.0  or  later. 
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•  640  Kbytes  of  memory. 

•  Expanded  Memory  System  recommended. 

•  A  hard  disk  with  3  Mbytes  of  free  space. 

•  A  1.44  Mbyte  3.5"  floppy  disk  drive. 

•  Color  Graphics  Adapter  (CGA) ,  Enhanced  Graphics  Adapter 
(EGA)  ,  Video  Graphics  Array  card  (VGA)  ,  AT&T  Graphics  card 
(ATT) ,  or  compatible. 

•  Borland  C++  Version  3.1  is  required  for  executable  file 
compiling.  Borland  C++  is  not  required  to  run  the  program. 

In  addition,  certain  variants  of  the  NFS  software  may 

require  additional  hardware: 

•  An  RS-232  port  for  software  executable  files  utilizing  the 
communications  port  for  data  reception  or  transmission. 

•  An  RS-422  port  or  RS-232  port  with  RS-422/RS-232  converter 
is  required  for  actual  TANS  GPS  data  collection. 

2 .  Disk  Contents 

The  NFS  software  is  in  compressed  format  on  one  or 
more  1.44  M  byte  3.5"  diskettes.  The  disk  should  include  the 
following  files: 

nps_32.zip  npsdat32.zip  nps_exe.zip  pkunzip.exe 

After  installation,  your  \STS51NPS  directory  will 
contain  the  following  subdirectories: 

NFS  NPS_SIM  TANS  TANS_SIM  ORBMECHl 

UTIL  INC  COM  TEST  OBJS 

The  STS51NPS  directory  contains  the  executable  files, 
the  current  International  Earth  Rotation  Service  (lERS)  data 
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file,  configuration  files  and  graphics  drivers  required  by  the 
program,  and  the  'makefile'  used  for  program  compilation. 
STS51NPS  files  include; 


att .bgi 
iers.dat 
ans . chr 
tans. os c 


cga.bgi 
litt . chr 
save_dat . bat 
turboc.cfg 


egavga.bgi 
makefile 
save_src.bat 
worldmap . dat 


gpsalm.dat 
nps . cfg 
tans . ild 
worldmap. raw 


The  STS51NPS  subdirectory  contains  executable  files 
included  in  'nps_exe.zip'  or  additional  files  when  created  by 
the  'makefile'  and  Borland  C++  Version  3.1.  These  include: 


tans . exe 

tans_spd . exe 

tans51sm.exe 

tans51fn.exe 

tsim.exe 

test_com.exe 

test_dev.exe 

com_txrx . exe 

vmode . exe 

scom.exe 

sdev . exe 

sdev_dly . exe 

sprp . exe 
sdsk . exe 


TANS,  with  NPS  ***  STS-51  Flight  Version  **+ 

TANS,  no  NPS,  with  SPDRIVE 

TANS,  with  NPS,  Sim  from  file 

TANS,  no  NPS,  testing 

TANS  device  simulator 

Corn-port  tester  (via  built-in  interrupts) 
Corn-port  tester  (via  DOS  device  driver) 
Corn-port  two-way  tester  (via  interrupts) 
Video -mode  switcher 

NPS  Simulator,  input  corn-port  (built-in),  no 
output 

NPS  Simulator,  input  corn-port  (DOS  driver) , 
no  output 

NPS  Simulator,  **post- flight  data  replay**, 
input  disk,  no  output 

NPS  Simulator,  input  propagator,  no  output 
NPS  Simulator,  input  disk,  no  output 
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smem . exe 

prp_dsk . exe 
prp_dev . exe 

prp_com.exe 

nps .  exe 
test_vec . exe 
map_raw . exe 
einin_test .  exe 
tansdump . exe 
tans  vec.exe 


NPS  Simulator,  input  memory  (frcan  disk)  ,  no 
output 

NPS  Generator,  input  propagator,  output  disk 
NPS  Generator,  input  propagator,  output 
com- port  (DOS  driver) 

NPS  Generator,  input  propagator,  output 
com- port  (built-in) 

NPS  Stand-alone,  **  STS-51  Flight  Version  ** 

Vector  functions  tester 

Map- file  converter,  text  to  raw 

EMM  functions  tester 

TANS  data- file  dumper 

TANS  data- file  vector  duit^er 


The  STS51NPS  subdirectory  will  also  include  several 
'.nps'  files  created  by  the  NPS  software  for  storing  plot 
information.  These  files  can  be  deleted  using  the  Dos  command 
'del  *.nps'  prior  to  program  start-up  if  the  user  does  not 
want  to  see  the  plots  from  an  earlier  run. 


The  NPS  subdirectory  contains  source  code  for  the  NPS 
program  shell  and  plotting  routines  along  with  several  other 
available  functions.  NPS  files  include: 

dif_data.c  dif_plot.c  f_and_g.c 
menupl o t . c  nps .  c 
nps_edit.c  nps_filt.c 
nps_none . c  nps_plot . c 
py_dat a . c  py_pl o t . c 


nps.h 
nps_m50 . c 


Isf ilter . c 
nps_dap . c 
nps_m50 .h 


nps  jpred . c  plane . c 
rv_data . c  rv_plot . c 
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The  NPS_SIM  subdirectory  contains  source  code  for  the 
program  shells  of  the  various  versions  of  the  progreim.  These 
variants  give  the  user  the  option  to  generate  simulated  state 
vectors  and  provide  them  to  the  progrcur.  for  program  testing 
and  simulation,  generate  state  vectors  and  send  them  to  a  file 
or  communications  port,  or  read  simulated  or  actual  state 
vectors  from  a  file,  communications  port,  or  memory.  NPS_SIM 
files  include: 

gcom_com.c  gcom_dev.c  gdisk.c  gnone.c 

nps_main.c  scorn. c  scom_dly.c  scom_old.c 

sdisK.c  sdisk_2.c  sim.c  sim.h 

smem . c  sprop . c  spropdsk . c 

The  ORBMECHl  subdirectory  contains  source  code  for  the 
Cowell  propagator.  The  propagator  includes  M50  to  WGS-84  and 
WGS-84  to  M50  conversions,  Jacchia  atmosphere  model  and  data 
files,  the  GEM- 9  gravity  model  and  forcing  functions,  and  the 
Runge-Kutta  fourth  order  integrator.  ORBMECHl  files  include: 
amatrix.c  bgprop.c  cowell.c  der.c 

gem9.c  getiers.c  gotpot.c  iers.h 

itowgs84.c  jacatm.c  jacdat.c  mBOrnp.c 

rk4.c  rnpd.c  rnpmSO.c  util.c 

util .h 
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The  UTIL  subdirectory  contains  source  code  for  '.c' 
and  '.asm'  utilities  used  by  the  program.  UTIL  files  include: 


edit  .c 

edit_fld.c 

edit_rt . c 

emm_cons . c 

emm_lowa . asm 

emm_map . c 

emm_mapm. c 

key_get . asm 

key_int9 . asm 

swap_d . asm 

swap_f . asm 

swap_s . asm 

tdbl_hms . asm 

tdbl_str.asm 

tgps_utc.c 

thms_dbl . asm 

thms_str .asm 

timer .asm 

v_j2000 .c 

v_m5  0 . c 

v_matrix. c 

v_quat . c 

v_rvbar . c 

v_vector . c 

The  TANS  and  TANS_SIM  subdirectories  contain  source 
code  for  the  DTO  700-6  level  I  TANS  GPS  code  written  by  Mike 
Arnie  for  NASA.  This  code  is  required  for  compiling  the 
integrated  program  and  is  included  for  completeness  but  will 


discussed  in 

this  report. 

TANS  files 

include : 

almanac . c 

almanac . h 

constant .h 

display . c 

display .h 

exit .c 

log.  c 

log.h 

m50_eph. c 

m50_eph.h 

main_dis . c 

map_dis . c 

map_dis . h 

misc_dis . c 

misc_dis.h 

misc_fun. c 

misc_fun.h 

nps_fake.c 

nps_if .c 

para_dis . c 

para_dis . h 

prc_tpkt . c 

prc_tpkt . h 

spc_edit . c 

spc_edit . h 

tans_sys . c 

tansSl . c 

tansSl . h 

tansf ile.h 

tanstime.c 

tanstime.h 

tglbtype.h 

tns_io_f . c 

tns_io_f . h 

tnsprtfn. c 

tnsprtfn.h 

tnsprtsm. c 
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TANS_SIM  files  include: 

tsim.c  tsim.h  tsim_2x.c  tsim_3x.c 

tsim_5x.c  tsim_ex.c  tsim_pkt.c 

The  INC  subdirectory  contains  source  code  for 

'include'  files  used  at  compile  time.  INC  files  include: 
comjport.h  com_port.inc  const. h  edit.h 

edit_rt.h  emm.h  keys.h  nps_if.h 

orbmechl.h  packet. h  pkt_if.h  swap.h 

tans_pkt.h  times. h  times. inc  types. h 

vector .h 

The  TEST  subdirectory  contains  source  code  for  various 
routines  written  to  develop  or  test  segments  of  the  NPS  code. 
TEST  files  include: 

com_txrx.c  emm_test.c  map_raw.c  pkt_cln.c 

pkt_show . c  tans_v2 . c  tans_vec . c  tansdump . c 

test.c  test_com.c  test_dev.c  test_vec.c 

testl.c  test2.c  vect_old.c  vmode.c 

The  COM  subdirectory  contains  source  code  for 

communications  routines  used  by  the  program  for  sending  and 
receiving  data  via  the  RS-232/422  port.  COM  files  include: 

com_inta.asm  com_intc.c  orb_file.c  orb_pkt.c 

orb_port.c  tans_pkt.c  tansfile.c  tansport.c 

tanspkt2 . c 
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The  OBJS  subdirectory  is  required  by  the  'makefile' 
and  becomes  the  repository  for  object  files  created  in  the 
compilation  process. 

Updates  to  the  NPS  software  may  contain  additional 
files  not  listed  cdsove. 

3 .  Program  Installation 

The  following  instructions  assume  drive  A  is  a  1.44  M 
byte  3.5"  floppy  disk  drive  and  drive  C  is  the  hard  disk.  If 
this  is  not  the  case,  stibstitute  the  correct  drive  designation 
when  following  the  instructions. 

1.  Create  a  directory  on  your  hard  disk  called  \STS51NPS 
and  set  it  to  the  current  directory: 

C>  C: 

C>  MKDIR  \STS51NPS 
C>  CD  \STS51NPS 

2.  Insert  the  floppy  disk  led^eled  STS_51  NPS  SOFTWARE  into 
drive  A  and  copy  the  contents  into  C:\STS51NPS: 

C>  A: 

A>  copy  * . *  C : 

A>  C; 

Remove  the  disk  from  drive  A. 

3.  Decompress  the  files  on  the  hard  disk  using  the  included 
PKUNZIP.EXE: 

C>  pkunzip  -d  -o  nps_32.zip 
C>  pkunzip  -d  -o  npsdat32.zip 
C>  pkunzip  -d  -o  nps_exe.zip 
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The  subdirectories  will  be  created  and  the  files  will 
automatically  be  decompressed  in  the  appropriate 
directories . 

4.  Make  an  OBJS  subdirectory  in  the  STS51NPS  directory: 

C>  MKDIR  \OBJS 

5.  If  using  Borland  C++  Version  3.1  to  compile  the  NPS 
software,  edit  the  'BCC_PATH' , ' LIBPATH' ,  and  'INCPATH' 
lines  in  the  'makefile'  in  the  STS51NPS  directory  to 
reflect  the  correct  path  of  'bcc.exe',  and  the  Borland 
C++  library  and  INCLUDE  files. 

This  completes  prograun  installation. 

4.  Configuration 

The  NPS  software  utilizes  the  memory  configuration 
file,  'nps.cfg',  located  in  the  'STS51NPS'  directory,  to 
reserve  RAM  for  program  use.  The  amount  of  memory  available  is 
system  dependent.  The  aimount  of  memory  required  by  the  prograun 
includes  the  executaible  file  and  the  sum  of  the  eight  plot 
history  buffers.  Most  systems  will  be  limited  to  a  total  of 
640  Kbytes.  Each  plot  history  buffer  can  hold  a  maximum  of  64 
Kbytes  of  data.  The  individual  plot  buffer  sizes  are  set  in 
the  configuration  file  to  the  desired  amount  using  any  ASCII 
editor.  The  expanded  memory  option  is  also  available  by 
editing  this  file. 

In  addition  to  the  'nps.cfg'  file,  the  graphics  driver 
files  (*.bgi),  character  files  (*.chr),  and  the  'iers.dat' 
file  must  be  present  in  the  STS51NPS  directory. 

The  'iers.dat'  file  contains  daily  variations  in  the 
Earth's  rotation  vector  from  the  Mean  of  1950  (M-50)  rotation 
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vector.  The  file  contains  data  for  a  90  day  window.  The 
program  has  been  coded  to  fail  if  propagation  is  attempted 
outside  the  90  day  window.  This  hard  coded  failure  can  be 
removed  but  the  propagations  would  assume  no  variation  in  the 
Earth's  rotation  vector  and  produce  erroneous  results.  The 
'iers.dat'  file  included  with  the  software  includes  the  STS-51 
flight  window.  For  current  lERS  data,  contact  the  US  Nav^  ^ 
Observatory. 

C.  Program  Cooqpiling 

The  included  makefile  and  Borland  C++  version  3,1  are  used 
to  compile  the  executable  files.  The  source  code  contains  pre¬ 
processor  commands  that  allow  customizing  the  compilation 
process  for  a  particular  program.  If  optimal  rendezvous 
prediction  functions  are  desired,  the  modifier  -DRNDZ  is  used. 
If  GPS  data  is  availeible,  the  modifier  -DGPS  is  used. 

For  example,  to  conpile  the  post -flight  analysis  version 
of  the  software,  "sdev_dly.exe",  including  optimal  rendezvous 
prediction  functions  and  GPS  data,  the  command  line  input 
would  be: 

C>  make  -DRNDZ  -DGPS  sdev_dly.exe 
The  "makefile"  was  created  this  way  in  order  to  allow 
compilation  of  the  smallest  possible  executable  file  and  still 
meet  the  operators  requirements.  NOTE  -  Versions  compiled 
without  the  full  capabilities  of  the  NPS  software  will  lack 
some  of  the  features  discussed  in  this  manual . 
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D.  Starting  th«  NPS  Prograa 

Once  the  desired  program  version  has  been  conpiled  using 
the  makefile  provided,  the  progrcun  can  be  executed.  Program 
initiation  procedures  depends  upon  the  version  being  run.  For 
the  integrated  TANS  GPS/NPS  version,  the  NPS  progreun  is  called 
from  the  TANS  GPS  progrcun  via  a  function  key.  For  stand  alone 
versions,  typing  the  executable  file  naune  at  the  DOS  prompt 
starts  the  program.  Some  versions  prompt  the  user  for 
information  at  start  up  (ie  communications  port  number,  data 
file  paths/naunes,  etc.).  These  are  self  explanatory. 

The  executadDle  file  "sdev_dly.exe"  included  is  used  to 
play  back  post -flight  data  and  is  a  good  version  to  start  with 
for  learning  the  program  operation.  The  program  needs  the 
"PCDecom"  data  packet  file  and  the  (optional)  TANS  GPS  data 
file  for  the  desired  time  period  of  the  flight. 

After  executing  "sdev_dly"  at  the  command  prompt,  the  user 
is  asked  to  provide  the  data  source.  The  default  is  corn-port 
two.  Over- write  the  default  with  the  data  file  name  (ie 
51_r.dat)  and  press  <ENTER>.  The  "SIM  MENU"  appears.  Press 
<Fl>  to  change  the  delay  time  between  data  points  in  the 
playback.  <ESC>  always  takes  the  user  back  to  the  previous 
menu.  From  the  "SIM  MENU"  press  <alt  S>  to  start  or  stop  the 
data  playback.  <F6>  is  used  to  enter  the  NPS  program. 
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I.  A  Program  Totu: 

Upon  entry  into  the  NPS  progrcun,  the  CRT  displays  a 
program  title,  four  M-50  state  vectors  in  raw  received  form 
and  in  post -propagated  form,  and  an  options  menu  containing  a 
choice  of  plot  displays  and  program  settings  menus.  From  the 
start-up  display,  the  user  can  immediately  see  if  data  is 
being  received  from  any  of  the  four  input  state  vector 
sources;  (1)  Orbiter  INS,  (2)  Orbiter  GPS,  (3)  Orbiter  target, 
and  (4)  SPAS  GPS. 

1.  Plot  Menu  Options 

The  NPS  software  presents  state  vector  comparisons  in 
three  different  forms:  (1)  the  R-bar/V-bar  plot,  (2)  the  state 
vector  difference  or  'Sawtooth'  plot,  and  (3)  the  Pitch/ Yaw 
display.  These  are  selectable  by  use  of  the  <FUNCTION>  keys  as 
noted  on  the  menu  bar. 

a.  R-bar/V-bar  Plots 

The  R-bar/V-bar  plot  displays  the  relative  motion 
between  a  target  and  a  chaser  vehicle  and  is  of  particular 
importance  during  rendezvous  and  proximity  operations.  The 
relative  motion  plot  uses  a  target -centered  coordinate  system 
in  which  the  Z-axis  rotates  with  the  target  and  is  positive 
directed  radially  toward  the  Earth,  the  x-cocis  is  curvilinear 
and  positive  in  the  direction  of  orbit  motion,  and  the  Y-axis 
is  out -of -plane  and  completes  the  right-hand  coordinate 
system.  (Figure  B-1.) 
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Figure  B>1.  R-bar/V-ber  plot. 


As  a  relative  motion  plot  is  normally  used  when  the 
phase  angle  between  the  target  and  chaser  is  small,  the 
coordinate  systems  used  in  a  relative  motion  plot  can  be 
thought  of  as  a  local  vertical/local  horizontal  (LVLH) 
coordinate  system  centered  at  the  target.  Thus,  if  the  chaser 
were  directly  below  the  target  on  the  radius  vector  to  the 
Earth's  center  (R-bar) ,  it  would  appear  on  the  4-z  axis  of  the 
relative  motion  plot.  Similarly,  if  the  chaser  was  ahead  of 
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the  target  on  the  target's  velocity  vector  (V-bar) ,  it  would 
appear  on  the  axis  on  the  relative  motion  plot. 

R-bar/V-bar  plots  are  selectively  availedjle  through 
the  use  of  <FUNCTION>  keys  for  the  following  target/chaser 
combinations  of  state  vectors: 

•  <F1>  SPAS  GPS/Orbiter  GPS 

•  <F2>  SPAS  GPS/Orbiter  INS 

•  <F3>  Orbiter  GPS/Orbiter  INS 

•  <F4>  SPAS  GPS/Orbiter  target 

•  <F5>  Orbiter  target/Orbiter  GPS 

•  <F6>  Orbiter  target/Orbiter  INS 

Plots  <F3>  and  <F4>  are  not  used  as  relative  motion 
plots.  These  are  used  as  another  method  of  viewing  the 
difference  vector  and  show  on  the  R-bar/V-bar  display  where 
the  inertial  navigation  system  thinks  the  Orbiter  or  SPAS  is 
located  relative  to  where  GPS  believes  it  is. 

R-bar/V-bar  plots  can  be  selected  from  the  main 
menu  or  from  any  other  plot. 
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b.  Sawtooth  Plots 

The  relative  difference  or  'Sawtooth'  plots  display 
the  difference  in  the  magnitudes  of  the  position  or  velocity 
vectors  of  two  source  vectors.  (Figures  B-2.,  B-3.)  This  is 
the  tool  used  to  quantify  the  error  between  the  inertial 
navigation  system  and  GPS.  The  results  from  these  plots  serve 
to  validate  or  invalidate  the  use  of  GPS  for  Orbiter  state 
vector  updating.  Two  'Sawtooth'  plots  are  selectively 
available  through  the  use  of  <SHIFT>  <FUNCTION>  keys: 

•  <SHIFT>  <F3>  Orbiter  GPS/Orbiter  INS 

•  <SHIFT>  <F4>  SPAS  GPS/Orbiter  target 

Once  a  'Sawtooth'  plot  has  been  selected,  the  <F9> 
key  toggles  the  plot  between  position  and  velocity  vector 
comparison. 

'Sawtooth'  plots  can  be  selected  from  the  main  menu 
or  from  any  other  plot. 

'Sawtooth'  plots  are  only  available  on  program 
versions  compiled  with  the  -DGPS  modifier. 


108 


MCC 

•wt-re 

■CM 

rio 

Alt  nanus 

Seu  •  TBT 

Settinga 

Figure  B~2.  Senile  Position  Difference  Sawtooth  plot. 


Figure  B-3.  Saaqple  Velocity  Difference  Sawtooth  plot. 
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c.  Pitch/ Yaw  Diaplaya 

The  Pitch/Yaw  display  gives  a  graphical 
presentation  of  the  Orbiter  (TOP  and  SIDE  views)  and  a  target 
pointing  vector  measured  in  pitch  up  from  Orbiter  body  X-axis 
and  yaw  about  the  rotated  Orbiter  body  Z-axis.  (Figure  B-4.) 
These  angles  are  computed  from  the  state  vectors  of  the 
Orbiter  and  target,  and  the  Orbiter  quaternion.  The  Pitch/ Yaw 
display  is  selected  with  the  <ALT><F5>  keys.  Target/chaser 
state  vector  source  combinations  for  the  Pitch/Yaw  plot  can  be 
selected  with  the  <F9>  key.  Choices  include: 

•  SPAS  GPS /Orbiter  GPS 

•  Orbiter  target/Orbiter  INS 

•  SPAS  GPS/Orbiter  INS 

The  Pitch/Yaw  display  can  be  selected  from  the  main 
menu  or  from  any  other  plot. 
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d.  Coanon  Plot  Features 

(1)  Plot  Labels 

All  plots  display  the  source  state  vector 
labels  and  the  day/time  of  the  most  recent  state  vector  from 
that  source  in  the  upper  left  hand  corner  of  the  display. 

(2)  Plot  History  Buffers 

The  R-bar/V-bar  and  'Sawtooth'  plots  each  have 
a  ring  buffer  for  storing  screen  displays.  This  permits  the 
user  to  leave  a  display  and  return  to  it  later  and  see  the 
historical  motion  or  difference  plot.  The  buffer  sizes  are  set 
in  the  'nps.cfg'  configuration  file.  The  maximum  buffer  size 
for  each  plot  is  64  kbytes.  The  type  of  plot  determines  the 
number  of  bytes  p^ar  data  point  required.  The  niomber  of  stored 
data  points  and  the  total  number  of  points  available  for  each 
plot  is  presented  in  the  lower  left  hand  comer  of  the 
display. 

(3)  Menu  Bars 

Menu  bars  are  used  to  assist  the  operator  by 
providing  a  quick  reference  of  available  functions  at  the 
bottom  of  the  display  screen.  The  multiple  menu  bars  are 
cycled  through  by  pressing  the  <SPACE>  bar  on  the  keyboard. 
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2.  Chang*  Sattlngs  Menu  Option 

The  NPS  software  package  includes  an  interactive 
settings  display  that  allows  the  user  to  manually  input  state 
vector  information,  alter  default  settings  and  data  used  by 
the  propagator,  change  default  screen  and  buffer  settings,  and 
adjust  parameters  in  the  thrust/predictor  mode  (discussed 
later)  .  The  'Change  Settings'  displays  are  entered  by  pressing 
<F10>.  <Page  Up>  and  <Page  Down>  are  used  to  display  the 
desired  settings  page.  There  are  seven  settings  pages: 

•  Sample  and  Step  Rates 

•  Propagation  Perturbations 

•  Orbiter  Inertial  State  Vector 

•  Orbiter  Target  State  Vector 

•  Orbiter  GPS  State  Vector 

•  SPAS  GPS  State  Vector 

•  Thrust  Information 


To  change 

a  setting  on  a 

display,  the  user  must 

advance 

the  curser 

to 

the  desired 

setting  using 

<TAB>  or 

< ENTER >, 

overwrite 

the 

setting,  and 

press  <ENTER> 

prior  to 

exiting  the  settings  menu. 
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Sanple  and  Step  Rates 


Souiqple  rates  (in  secs,  0  «  fast) 
plots  show:  0 
buffer  save:  10 

Orb -GPS  filter  save:  9 

auto- rerun:  N  rerun  delay:  300 


Step  size  for  propagation  (in  secs) :  10 
Maximxim  propagation  time  (in  secs)  :  1800 

Position  pre  ctor  settings 
Points  to  splay:  40 
Step  size  secs) :  60 

Auto -mode  delay:  8 


a.  Saaf)le  and  Step  Rates  Page 

The  Sample  and  Step  Rates  page  displays  for  editing 
plot  show  rate,  buffer  save  rate,  Orbiter  GPS  filter  save 
rate,  filter  auto- rerun  and  rerun  delay  rate,  propagator  step 
size,  maximum  valid  propagation  time,  and  predictor  settings. 
These  parameters  are  defined  below. 

•  Plot  Show  Rate  -  minimum  time,  in  seconds,  between  screen 
writes  of  relative  motion  data. 

•  Buffer  Save  Rate  -  minimum  time,  in  seconds,  between  plot 
data  points  recorded  in  the  plot  buffer  files. 

•  Orbiter  GPS  Filter  Save  Rate  -  minimum  time,  in  seconds, 
between  TANS  GPS  state  vectors  stored  in  the  GPS  filter 
buffer. 

•  Orbiter  GPS  Filter  Auto-Rerun  Switch  -  ON/OFF  switch  for 
the  filter  auto-rerun  feature.  When  active,  the  filter 
will  execute  and  solve  for  a  new  filtered  state  vector  to 
propagate  from  every  rerun  delay  rate. 


•  Propagator  Step  Size  -  Time  increment,  in  seconds,  for  the 
orbit  propagator  to  step  forward  with. 

•  Maximxim  Valid  Propagation  Time  -  The  maximum  time,  in 
seconds,  that  the  propagator  will  propagate  forward  to. 

•  Position  Predictor  Points  to  Display  -  Number  of  Predictor 
points  (defaulted  to  minutes)  to  display. 

•  Position  Predictor  Step  Size  -  Step  size,  in  seconds 
between  predictor  points. 

•  Predictor  Auto-mode  Delay  -  Delay,  in  seconds,  between 
execution  of  automatic  predictions  when  in  AUTO  PREDICT 
mode . 

All  times/rates  are  in  seconds. 
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Propagation  Perturbations 

Drag  Mode  on:  Y 

Ballistic  numbers 
Orbiter:  64 
Payload:  64 

Drag  Information 

Solar  Flux:  185.959340379 
Mean  Solar  Flux:  178.644769060 
Geomagnetic  Activity  Index:  178.644769868 

Propagator  Information 
Zonal  Harmonics:  4 
Tesseral  Harmonics:  4 


b.  Propagation  Perturbations  Page 

The  Propagation  Perturbation  page  allows  editing  of 
the  current  propagator  parameters.  These  include: 

•  Drag  Mode  Status  -  ON/OFF  switch  for  use  of  drag  forces  in 
the  propagator.  Default  is  ON. 

•  Orbiter/target  Ballistic  Nximbers  -  Ballistic  coefficients 
(m/CoA)  for  Orbiter  and  target  used  in  determining  drag 
forces . 

•  Solar  Flux  -  The  predicted  F-10.7  solar  activity  index. 
This  parcuneter  affects  the  height  of  the  atmosphere  and, 
hence,  the  atmospheric  drag. 

•  Mean  Solar  Flux  -  The  90  day  average  solar  activity  index. 
This  parameter  affects  the  height  of  the  atmosphere  and, 
hence,  the  atmospheric  drag. 

•  Geomagnetic  Activity  Index  -  Measurement  of  the  Earth's 
magnetic  activity. 

•  Zonal /Tesseral  Harmonics  -  The  number  of  harmonic  terms  of 
the  geopotential  function  to  include  in  the  gravity  model 
(up  to  30)  .  Using  more  harmonics  increases  the  accuracy  of 
the  propagator  at  the  cost  of  increased  computation  time. 
Default  is  4/4. 


116 


Orbiter  GPS  State  Vector 


Position  x:  15432.6498524 
Kft  y:  -15172.9904659 
z:  0.971861685925 

Velocity  x:  17.9049415653 
Kft/s  y:  18.1705472718 

z:  -0.00226579476339 

Time  (ddd/hh:mm:ss) ;  211/06:30:00.000 

Use  Realtime  Vector:  Y 

Apply  time  correction:  N  (delta  in  secs) :  0 
Source  for  GPS  vector  (0  GPS-M50,  1  GPS-WGS84) :  0 
Converter  for  WGS84-M50  (0  iload  file,  1  computed) :  0 


c.  State  Vector  Pages  (4) 

The  State  Vector  Pages  present  and  allow  )ceyboard 
entry  of  each  of  the  four  state  vector  inputs.  Definable 
paramieters  include: 

•  State  Vector  Position  -  M-50  inertial  coordinates  X,  Y, 
and  Z  in  kilofeet. 

•  State  Vector  Velocity  -  M-50  inertial  velocity  Vx,  Vy,  and 
Vz  in  kilofeet/sec. 

•  Time  -  The  universal  time  stamp  of  the  given  state  vector 
in  day  of  the  year,  hour,  minute,  and  second. 

•  Use  Realtime  Vector  -  An  ON/OFF  flag,  determines  whether 
or  not  to  accept  new  state  vectors  from  the  TANS  or  the 
Orbiter' s  Navigation  computer.  This  option  would  be  turned 
off  in  the  event  of  erroneous  data  from  the  online 
sources.  Propagation  would  then  take  place  from  the  last 
given  or  hand  keyed  state  vector  shown  on  the  page. 
Default  is  ON. 
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•  Apply  Time  Correction  -  An  ON/OFF  flag.  OFF  accepts  the 
time  tag  of  a  state  vector  as  is.  ON  modifies  the  time  tag 
by  a  specified  number  of  seconds.  Default  is  OFF. 

GPS  source  State  Vector  Pages  include  the  following  additional 

options; 

•  Source  for  GPS  State  Vector  -  Flag  for  determining  source 
state  vector  coordinate  system,  M-50  or  WGS-84.  Default  is 
M-50. 


•  Converter  for  WGS-84  to  M-50  -  Flag  for  determining 

conversion  scheme  of  WGS-84  state  vector  to  M-50  state 
vectoi .  The  ' iload  file'  option  uses  a  data  file  with  a 
conversion  matrix  for  a  specified  recent  date  and  the 
converter  uses  the  matrix  modified  for  the  passage  of  time 
sine-:  the  file  date.  The  'computed'  option  performs  the 
complete  WGS-84  to  M-50  conversion  for  each  state  vector. 
The  'computed'  option  costs  more  confutation  time.  Default 
is  'iload  file'. 
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Thrust  information  (ft/s) 
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DAP-B 

+x 

up 

0.016000 

0.002820 
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down 

-0.016000 

0.002700 
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0.024000 

+z 

in 

-0.034000 

(low- z) 

+z 

out 

0.013000 

+z 

in 

-0.034000 

Future  thrust;  N  Note: future  thrusts  use  the  current 

Now  +  000/00:00:00.000  attitude,  so  answers  are  valid 

or  at  211/04:27:00.000  only  during  inertial  hold,  the 

alternative  is  to  apply  thrust  in 
LVLH 

Thrust  in  LVLH;  N 

Thrust  on;  N  Total  thrust  (XYZ) :  0.0000  0.0000  0.0000 


TR  {Do  NOT  pick  whole  orbit  intervals!):  000/01:00:00.000 


d.  Tbruat  Information  Page 

The  Thrust  Information  Page  presents  and  allows 
keyboard  entry  of  thrust  vector  data  to  be  used  by  the 
predictor  for  displaying  predicted  relative  motion  based  upon 
planned  thruster  firings.  Parameters  include: 

•  DAP-A/DAP-B  Single  Impulse  Thrust  Settings  -  Orbiter 
impulse  thrust  components  for  the  Digital  Auto- Pilot  (DAP) 
A  and  B  modes  in  feet  per  second.  Default  settings  shown 
are  actual  values  for  the  Orbiter  thruster  system. 

•  Future  Thrust  -  An  ON/OFF  flag  for  future  thrust  relative 
motion  predictor  function.  This  function,  when  activated, 
allows  the  programming  of  thruster  firings  at  a  specified 
time  in  the  future  and  displays  the  predicted  relative 
motion  on  the  R-bar/V-bar  display  along  side  the  predicted 
motion  of  the  Orbiter  without  thruster  inputs. 

•  Future  Thrust  Activation  Time  -  Time  (ddd/hh/mm/ss)  of 
desired  thrust  inputs  relative  to  present  time  or  in 
absolute  UTC. 

•  Thrust  in  LVLH  -  An  ON/OFF  flag.  ON  indicates  thruster 
inputs  are  in  the  LVLH  coordinate  system.  OFF  indicates 
thruster  inputs  are  in  Orbiter  body  coordinates.  Default 
is  OFF. 

•  Thrust  On  -  ON/OFF  flag  indicating  if  the  thrust  function 
is  active.  Default  is  OFF. 

•  Total  Thrust  -  Current  thruster  settings  (XYZ)  in  feet  per 
second. 

•  Time  to  Rendezvous  (TTR)  -  Input  time  used  by  the  program 
Rendezvous  function  for  determining  the  optimal  two 
impulse  rendezvous  thrusts.  This  time  cannot  be  a  multiple 
of  the  orbital  period  due  to  singularities  in  the 
function.  Default  is  one  hour. 

3.  Additional  Functions  and  Program  Features 

An  assortment  of  tools  and  features  were  included  in 
the  NPS  software  to  provide  additional  information  to  the 
user.  These  features  can  be  found  on  the  menu  bar  at  the 
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bottom  of  each  plot.  Multiple  menu  bars  are  availeJ^le  and  can 
be  cycled  through  by  pressing  the  <SPACE>  bar. 

a.  Plot  Scaliog/Shiftiog 

All  R-bar/V-bar  plots  are  Independently  scaladale  In 
the  V-bar  and  R-bar  direction.  V-bar  scaling  Is  accomplished 
through  the  use  of  left  and  right  <arrow>  keys.  Similarly,  R- 
bar  scaling  Is  acconqpllshed  with  the  up  and  down  <arrow>  keys. 

All  'Sawtooth'  plots  are  scalalble  In  magnitude  (Y) 
and  time  (X)  with  the  same  arrow  key  scheme. 

Plot  shifting  (left, right, up, down)  Is  available  on 
all  R-bar/V-bar  and  'Sa%^ooth'  plots  In  a  similar  manner  to 
plot  scaling  using  the  <CTRL><arrow>  keys. 

b.  Fast  Pitcb/Yaw 

If  the  program 

operator  desires  current 

pltch/yaw  Information  while 
remaining  In  an  R-bar/V-bar 
plot,  the  Fast  Pitch/Yaw 
option,  <ALT><F6>,  Is 
available.  This  option 
displays  the  target's 

current  pitch  and  yaw  angles 
In  degrees  and  range  In  the 
upper  left  hand  corner  of  the  current  plot.  (Figure  B-5.)  The 
Fast  Pitch/Yaw  function  Is  a  one  time  calculation  at  time  of 
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execution,  freeing  up  CPU  time  that  is  used  for  continuous 
pitch/yaw  plotting  in  the  <ALT><F5>  Pitch/Yaw  display, 
c.  Predictors 

Relative  motion  prediction  is  availed>le  by 
propagating  the  orbits  ahead  in  time,  allowing  the  user  to  see 
where  the  Orbiter  will  be  in  the  future.  The  predictor 
function  can  be  singularly  executed  for  a  one-time  prediction, 
<F7>,  or  placed  in  an  automatic  update  mode,  <F8>.  Initiation 
of  the  predictor  displays  the  future  position  of  the  Orbiter 
on  the  screen  in  increments  set  by  the  user.  The  default 
settings  are  for  ten  points  at  one  minute  intervals.  Both  the 
number  of  points  and  the  interval  are  adjusteUsle  by  changing 
settings  in  the  'Sanple  and  Step  Rates'  Page  of  the  Change 
Settings  <F10>  function. 
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d.  H~bar  Display 


The  R-bar/V-bar  plot  does  not  include  out -of -plane 
component  information.  To  provide  this  information  visually, 
the  H-bar,  or  momentum  vector  component  of  displacement  can  be 
displayed  in  the  upper  right  hand  corner  of  the  screen.  This 
display  is  toggled  On  or  Off  by  the  <ALT><F9>  key.  Default 
setting  is  On. 

e.  GPS  Filter 

The  progreun  contains  a  least  squares  fit  GPS  state 
vector  filter  developed  by  the  McDonnell  Douglas  Corporation 
for  NASA.  TANS  GPS  State  vectors  provide  high  position 
accuracy  on  the  order  of  a  few  hundred  feet.  TANS  velocity 
vectors  are  not  so  accurate  with  errors  on  the  order  of  one 
meter  per  second.  For  state  vector  propagations  over  short 
periods  of  time  this  is  manageable.  For  longer  propagations, 
the  velocity  error  can  cause  significant  errors  in  the 
propagated  state.  The  purpose  of  a  filter  is  to  smooth  the 
errors  in  position  and  velocity  so  that  long  propagations  may 
be  used  in  the  event  the  TANS  unit  is  switched  off  or  stops 
functioning. 

The  filter  is  implemented  by  the  <CTRL><F1>  keys. 
This  filter  maintains  a  state  vector  buffer  of  the  latest 
sixty  Orbiter  GPS  state  vectors.  In  the  event  that  the  Orbiter 
GPS  state  vector  is  lost  due  to  a  TANS  failure,  the  GPS  filter 
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function  solves  for  a  smoothed  state  vector  to  continue 
propagation  with. 

f.  DAP  mode 

The  Digital  Autopilot,  or  DAP,  mode  allows  the  user 
to  input  thruster  firings  at  present  or  future  times  to 
excunine  the  resulting  relative  motion  on  the  R-bar/V-bar  plot. 
Activation  of  the  DAP  mode  key  <CTRL><F7>  displays  the  DAP 
menu  bar.  The  DAP  mode  menu  consists  of  the  following  options: 

•  DAP- A/DAP- B  Mode  <a>/<b>  -  Toggles  the  DAP  mode  between 
DAP- A  and  DAP-B.  This  is  essentially  a  change  in  the 
magnitudes  of  thruster  impulses. 

•  Low  Z  Mode  <z>  -  Toggles  the  DAP  mode  between  normal  mode 
where  maximum  efficiency  of  thruster  is  desired,  and  Low 
Z  mode  where  plume  impingement  on  a  nearby  object  located 
above  the  Orbiter  payload  is  the  primary  concern. 

•  LVLH/Body  Mode  <L>  -  Toggles  the  DAP  mode  to  recognize 
thruster  inputs  in  Orbiter  body  or  Local  Vertical  Local 
Horizontal  coordinates. 

•  Left/Right/Up/Down  <arrow>  keys  -  manually  adjust  the 
input  thrust  one  impulse  per  key  depression. 

•  Reset  <SPACE>  -  Turns  DAP  mode  display  off. 

•  Redisplay  <ENTER>  -  Refreshes  display  with  current  DAP 
mode  thruster  settings. 


Thruster  firings  can  be  entered  in  LVLH  or  Orbiter  body 
coordinates  by  the  arrow  keys  in  this  mode,  or  alternatively 
from  the  Change  Settings  <F10>  Thrust  Information  page.  From 
the  Thrust  Information  page,  the  time  of  thrust  implementation 
may  be  set  allowing  for  viewing  of  future  Orbiter  motion  based 
on  planned  maneuvers. 
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NOTE  -  Upon  entering  the  DAP  mode,  keyboard  control 
is  turned  over  to  the  DAP  mode  keyboard  handler.  NPS  keyboard 
functions  such  as  scaling  or  plot  selection  are  not  available 
in  this  mode.  Keyboard  control  is  returned  to  the  NPS  keyboard 
handler  upon  exiting  DAP  mode  (<ESC>  key) . 
g.  Rendezvous  Predictor 

The  rendezvous  predictor  function,  <CTRL><F6>,  is 
an  application  of  the  two  impulse  optimal  rendezvous 
algorithm.  When  activated,  the  rendezvous  predictor  solves  for 
the  thrust  required  to  complete  the  rendezvous  and  applies 
this  thrust  to  the  predictor.  This  function  is  available  only 
when  the  progrcun  is  compiled  with  the  -DRNDZ  modifier. 
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